2,000 Greater & Lesser Mysteries/2,000 Greater and Lesser Mysteries.iso/computer/virus/mys00501.txt

Text File | 1994-06-10 | 1.3 MB | 31,673 lines

[ Last modified 23 January 89 - Ken van Wyk ]

Welcome!  This is the  semi-monthly introduction posting   to VIRUS-L,
primarily for the benefit of any newcomers  to the list.   Many of you
have probably already seen  a message (or two...)  much like this, but
it does change from time to time, so I would appreciate it if you took
a couple of minutes to glance over it.



What is VIRUS-L?

It is an electronic mail discussion forum for sharing  information and
ideas about computer  viruses.  Discussions should include   (but  not
necessarily  be limited to): current  events  (virus sightings), virus
prevention    (practical  and   theoretical),    and  virus    related
questions/answers.   The list  is moderated  and digested.  That means
that  any message coming  in gets  sent  to  me,  the  editor.  I read
through the messages and make sure  that they adhere to the guidelines
of the list (see below) and add them to the  next digest.  Weekly logs
of digests are kept by the LISTSERV (see below  for  details on how to
get them).  For  those interested in statistics,  VIRUS-L is now (Jan.
23, 1989) up to 950  direct subscribers.  Of  those, approximately  80
are local redistribution accounts with an unknown number of readers.

As stated above, the list is digested and moderated.  As such, digests
go out when a) there are enough messages for  a digest, and  b) when I
put all incoming (relevant) messages into the digest.  Obviously, this
can   decrease   the  timeliness of urgent    messages such  as  virus
warnings/alerts.  For that, we have a sister list called VALERT-L.  It
is unmoderated  and undigested  - anything  going in  to the list goes
directly  out  to  all  the  subscribers, as  well  as  to VIRUS-L for
inclusion in the  next available  digest.   VALERT-L is for  the  sole
purpose of  rapidly sending out  virus alerts.   Anyone who  does  not
adhere to this  one guideline of  VALERT-L will be immediately removed
from the list.   That is, no news   is good  news.  Subscriptions  and
deletions to  VALERT-L are  handled identically as  those  for VIRUS-L
(see instructions below).


What VIRUS-L is *NOT*?

A place to  spread hype about  computer  viruses;  we already have the
Press for that.  :-) A place to sell things, to panhandle, or to flame
other subscribers.  If anyone *REALLY* feels the need to flame someone
else for something that they may have  said, then the flame  should be
sent directly to that person and/or to the list moderator  (that would
be me, <[e-mail]>).


How do I get on the mailing list?

Well, if you are  reading this, chances are *real  good* that  you are
already on the list.  However, perhaps this  document was given to you
by a friend or colleague...  So, to get onto the VIRUS-L mailing list,
send a mail message to <[e-mail]>.  In the body of the
message, say nothing more than SUB  VIRUS-L your name.  LISTSERV  is a
program which automates mailing lists such as VIRUS-L.  As long as you
are either on BITNET, or any network accessible to BITNET via gateway,
this  should work.  Within  a short time, you will  be  placed  on the
mailing list, and you will get confirmation via e-mail.


How do I get OFF of the list?

If, in  the unlikely  event, you should  happen  to want to be removed
from  the   VIRUS-L     discussion    list,   just    send   mail   to
<[e-mail]>  saying  SIGNOFF VIRUS-L.   People, such as
students, whose accounts are going to be closed (for example, over the
summer...) - PLEASE signoff of  the list before  you leave.  Also,  be
sure to send your signoff request to the LISTSERV and  not to the list
itself.  Note that the appropriate node  name is LEHIIBM1, not LEHIGH;
we have a node called LEHIGH, but they are *NOT* one and the same.


How do I send a message to the list?

Just send electronic mail  to  <[e-mail]>  and it  will
automatically be sent to the editor for possible inclusion in the next
digest to go out.


What does VIRUS-L have to offer?

All  VIRUS-L  digests  are stored in  weekly   log  files which can be
downloaded by  any user on  (or off) the mailing  list.  Note that the
log files contain all of the digests from a particular week.  There is
also a small archive  of some of the  public anti-virus programs which
are currently available.  This  archive, too,  can be accessed  by any
user.  All  of this is  handled automatically by the  LISTSERV here at
Lehigh University (<[e-mail]>).


How do I get files (including log files) from the LISTSERV?

Well, you will first want  to know what  files are   available on  the
LISTSERV.  To do this, send mail  to <[e-mail]> saying
INDEX VIRUS-L.   Note   that filenames/extensions  are  separated by a
space, and not by a period.  Once  you  have decided which file(s) you
want,  send   mail to  <[e-mail]> saying  GET filename
filetype.  For example, GET VIRUS-L LOG8804 would get the  file called
VIRUS-L LOG8804 (which happens to be the  monthly  log of all messages
sent to VIRUS-L during   April,  1988).  Note  that, starting  June 6,
1988, the logs  are weekly.  The  new file format is  VIRUS-L LOGyymmx
where yy is  the year  (88, 89, etc.),  mm is the  month, and x is the
week (A, B, etc.).  Readers who prefer digest format lists should read
the  weekly logs  and sign   off   of   the  list  itself.  Subsequent
submissions to the list should be sent to me for forwarding.

Also available is a  LISTSERV at SCFVM which  contains more anti-virus
software.   This  LISTSERV  can  be  accessed  in  the  same manner as
outlined   above,   with  the    exceptions  that    the  address   is
<[e-mail]> and that the commands to  use are INDEX PUBLIC
and GET filename filetype PUBLIC.


What is uuencode/uudecode, and why might I need them?

Uuencode and uudecode are two programs which convert binary files into
text (ASCII) files and back  again.  This  is so binary  files can  be
easily transferred via  electronic mail.  Many  of  the files on  this
LISTSERV  are binary files  which are stored in uuencoded  format (the
file types will be  UUE).  Both uuencode  and  uudecode  are available
from the LISTSERV.  Uudecode is available in BASIC and in Turbo Pascal
here.  Uuencode is available in Turbo  Pascal.  Also, there  is a very
good binary-only uuencode/uudecode  package on the LISTSERV  which  is
stored in uuencoded format.


Why have posting guidelines?

To keep the discussions on-track with what the list is intended to be;
a vehicle for virus  discussions.   This will keep the network traffic
to a minimum and, hopefully, the quality of the content of the mail to
a maximum.



What are the guidelines?

     Try to keep messages relatively short and to the  point, but with
     all relevant information included.   This serves a  dual purpose;
     it keeps network traffic to  a necessary minimum, and it improves
     the likelihood of readers reading your entire  message.

     Personal information and  .signatures  should   be  kept to   the
     generally accepted maximum of 5   lines of text.  The editor  may
     opt  to shorten  some lengthy   signatures (without deleting  any
     relevant  information, of course).  Within   those  5 lines, feel
     free to be a bit, er, creative if you wish.

     Anyone  sending  messages   containing, for  example,   technical
     information should   *PLEASE*  try  to  confirm their  sources of
     information.  When possible, site  these sources.  Speculating is
     frowned upon -  it merely  adds confusion.  This editor does  not
     have the time to confirm all contributions  to  the list, and may
     opt to discard messages which do not appear to have valid sources
     of information.

     All messages sent  to  the list  should have appropriate  subject
     lines.  The subject lines should  include the type of computer to
     which the message  refers, when applicable.  E.g., Subject: Brain
     virus detection (PC).  Messages without appropriate subject lines
     *STAND A GOOD CHANCE OF NOT BEING INCLUDED IN A DIGEST*.

     As already  stated, there will  be no flames  on the list.   Such
     messages will be discarded.

     The same goes for any commercial plugs or panhandling.

     Submissions  should be directly   or indirectly   related  to the
     subject of computer viruses.  This one is particularly important,
     other subscribers really  do not want to  read  about things that
     are  not  relevant  -    it only  adds to  network    traffic and
     frustration for the people reading the list.

     Responses to queries should be sent  to the author of  the query,
     not to the entire list.  The author should then send a summary of
     his/her responses to the list at a later date.

     "Automatic  answering machine" programs (the ones  which reply to
     e-mail for you when you are gone) should be set to *NOT* reply to
     VIRUS-L.  Such  responses sent to  the entire list are  very rude
     and will be treated as such.

     When sending in a submission, try  to see whether or  not someone
     else  may have just said  the same  thing.   This is particularly
     important when  responding to postings   from someone else (which
     should be sent to that person *anyway*).  Redundant messages will
     be sent back to their author(s).

Thank-you for your time  and for your  adherence to these  guidelines.
Comments and suggestions, as always, are invited.  Please address them
to me, <[e-mail]> or <[e-mail]>.


Ken van WykVIRUS-L Digest   Tuesday,  2 Jan 1990    Volume 3 : Issue 1

Today's Topics:

Re: WDEF / Apology to Mainstay Software (Mac)
Tracking Infections
Re: AIDS TROJAN RESEARCH
Call for Papers --- 13th National Computer Security Conference
Questions re VIRUS-L
Re: DES Availability
Re: Virus trends
Comments Attributed to SWE
AIDS Program (PC)
Ascii 255
"Do not use this Diskette"
Spafford's Theorems
Re: Virus Trends

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

---------------------------------------------------------------------------

Date:    Fri, 22 Dec 89 16:17:00 -0500
From:    [e-mail]
Subject: Re: WDEF / Apology to Mainstay Software (Mac)

[e-mail] writes:

> 1st Aid Software deserves a great deal of credit for having the only
> virus prevention tool that was capable of catching WDEF.  Everybody
> else failed, including Symantec's SAM, HJC's Virex, Gatekeeper, and
> Vaccine.  I don't know about MainStay's AntiToxin - I don't have a
> copy of that either (yet).

Disinfectant 1.5 can also catch/remove WDEF virus.

 Binod Taterway, User Consultant, Lehigh University Computing Center
 Lehigh University, Bethlehem, PA 18015.         Tel: [phone]
 E-mail: [e-mail] (Internet),     [e-mail]

------------------------------

Date:    Fri, 22 Dec 89 16:07:21 -0600
From:    "McMahon,Brian D" <[e-mail]>
Subject: Tracking Infections

The current flurry of WDEF infection reports has reawakened a long-standing
interest of mine in tracking the propagation of nasties (term intended to
include both virus and Trojan horse).  I know people will occasionally post
messages to this list along the lines of, "If anyone's keeping track of
infection reports...", but this seems to be rather sporadic and haphazard.

Question:  Who is collecting such information, and in what form?  I would
certainly be willing to offer my assistance in the collection effort, but
how much of this wheel has already been invented, and what remains to be
done?

Going one step further, what if we were to formalize the procedure of
reporting, at least for the academic sites, by enlisting "spotters" at
various institutions, who would then file a brief report on any infections
at their location?  Microcomputer coordinators and user-support staffers
would be likely candidates.  This is a suggestion for discussion, so I'd
welcome any feedback, positive or negative.

Brian McMahon  <[e-mail]>
Academic Programmer
Grinnell College
Grinnell, Iowa 50112
[phone]

Standard disclaimer ... my opinions only. <mumble>

------------------------------

Date:    Fri, 22 Dec 00 19:89:01 +0000
From:    microsoft![e-mail]
Subject: Re: AIDS TROJAN RESEARCH

>              AIDS "TROJAN" DISK UPDATE - DECEMBER 17, 1989
>
> First, let us say for the record that everything reported so far by
> Mr. McAfee is correct. Our tests bear out the results he has obtained.
>
> A form of public key encryption is then used to perform the actual
> encryption. This was determined by the brute force decryption method.
> SWE has several 80486's and access to a VAX and they were put to work
> decrypting the files. It was made easier by the fact that the original
> contents of the test disk were known. One nasty little trick the AIDS
> "trojan" uses is that after each file is encrypted the encryption key
> is modified slightly.

Can either of you shed some light on the above message?  It contains
serious contradictions with both itself and the statements of Mr.
McAfee with whom it purports to agree.

The comments about DES and public key encryption contained in the
above message are extremely confused.  All indication is that the AIDS
trojan does simple substitutions on file names.  The above message
claims that the entire disk is encrypted with a public key encryption
scheme.

My conclusion is that this message was not posted in good faith.  The
last thing anyone needs is this kind of purposeful misinformation.
This conclusion is supported by the claim that the so-called SWE
company has moved and "returned" their sample disks to the owners.

By associating yourselves with this nonsense, you have seriously impaired
your reputations.

sincerely,

Alonzo Gariepy
alonzo@microsoft

------------------------------

Date:    Sat, 23 Dec 89 08:59:00 -0500
From:    Jack Holleran <[e-mail]>
Subject: Call for Papers --- 13th National Computer Security Conference

CALL  FOR  PAPERS:

           13th NATIONAL COMPUTER  SECURITY CONFERENCE
                          Sponsored by
            the National Computer Security Center
                               and
       the National Institute of Standards and Technology

Theme:    Information Systems Security:  Standards - The Key to the Future

Date:                   OCTOBER 1-4, 1990

Location:                WASHINGTON, D.C.

This conference provides a forum for the Government and the private sector to
share current information that is useful and of general interest to the
conference participants on technologies, present and future, that are designed
to meet the ever-growing challenge of telecommunications and automated
information systems security.  The conference will offer multiple tracks for
the needs of users, vendors, and the research and development communities.
The focus of the conference will be on: Systems Application Guidance,
Awareness, Training, and Education, Ethics and Issues, Evaluation and
Certification, Innovations and New Products, Management and Administration,
and Disaster Prevention and Recovery.  We encourage submission of papers on
the following topics of high interest:

Systems Application Guidance
    -    Access Control Strategies
    -    Achieving Network Security
    -    Building on Trusted Computing Bases
    -    Integrating INFOSEC into Systems
    -    Preparing Security Plans
    -    Secure Architectures
    -    Securing Heterogeneous Networks
    -    Small Systems Security

Innovations and New Products
    -    Approved/Endorsed Products
    -    Audit Reduction Tools and Techniques
    -    Biometric Authentication
    -    Data Base Security
    -    Personal Identification and Authentication
    -    Smart Card Applications
    -    Tools and Technology

Awareness, Training and Education
    -    Building Security Awareness
    -    Compusec Training:  Curricula, Effectiveness, Media
    -    Curriculum for Differing Levels of Users
    -    Keeping Security In Step With Technology
    -    Policies, Standards, and Guidelines
    -    Understanding the Threat

Evaluation and Certification
    -    Assurance and Analytic Techniques
    -    Conducting Security Evaluations
    -    Covert Channel Analysis
    -    Experiences in Applying Verification
    -    Formal Policy Models
    -    Techniques

Management and Administration
    -    Accrediting Information Systems and Networks
    -    Defining and Specifying Computer Security Requirements
    -    Life Cycle Management
    -    Managing Risk
    -    Role of Standards
    -    Security Requirements

Disaster Prevention and Recovery
    -    Assurance of Service
    -    Computer Viruses
    -    Contingency Planning
    -    Disaster Recovery
    -    Malicious Code
    -    Survivability

Ethics and Issues
    -    Computer Abuse/Misuse
    -    Ethics in the Workplace
    -    Individual Rights
    -    Laws
    -    Relationship of Ethics to Technology
    -    Standards of Ethics in Information Technology


BY FEBRUARY 16, 1990:  Send eight copies of your draft paper* or panel
suggestions to one of the following addresses.  Include the topical category
of your submission, author name(s), address, and telephone number on the cover
sheet only.

    1.  FOR PAPERS SENT VIA        National Computer Security Conference
          U.S. or Foreign             ATTN:  NCS Conference Secretary
         Government  MAIL             National Computer Security Center
              ONLY:                   Fort George G. Meade, MD 20755-6000

    2.   FOR PAPERS SENT VIA       National Computer Security Conference
         COMMERCIAL COURIER           c/o NCS Conference Secretary
       SERVICES (e.g.-FEDERAL         National Computer Security Center
         EXPRESS, EMERY, UPS,         911 Elkridge Landing Road
              etc.):                  Linthicum, MD  21090

    3.  FOR Electronic Mail:  [e-mail]   (1 copy)

BY MAY 4, 1990: Speakers selected to participate in the conference will be
notified.

BY JUNE 22, 1990:  Final, camera-ready papers are due.

 * Government employees or those under Government sponsorship must so identify
their papers.

For additional information on submissions, please call [phone].

     To assist the Technical Review Committee, the following is required for
all submissions:

        Page 1:     Title of paper or submission
                           Topical Category & keywords
                           Author(s)
                           Organization(s)
                           Phone number(s)
                           Net address(es), if available
                           Point of Contact
     Additionally, submissions sponsored by the U.S. Government must provide
the following information:
                        U.S. Government Program Sponsor or Procuring Element
                        Contract number (if applicable)
                        U.S. Government Publication Release Authority
                           (Note:  Responsibility for U.S. Government
                            pre-publication review lies with the author(s).)

      Page 2:      Title of the paper or submission
        -last       abstract
                    The paper   (Suggested length:  6 pages, double columns)

     A Technical Review Committee, composed of U.S. Government and Industry
Computer Security experts, will referee submissions only for technical merit
for publication and presentation at the National Computer Security (NCS)
Conference.  No classified submissions will be accepted for review.

     Papers drafted as part of the author's official U.S. Government duties
may not be subject to copyright.  Papers submitted that are subject to
copyright must be accompanied by a written assignment to the NCS Conference
Committee or written authorization to publish and release the paper at the
Committee's discretion.  Papers selected for presentation at the NCS
Conference requiring U.S. Government pre-publication review must include,
with the submission of the final paper no later than June 22, 1990 to the
committee, a written release from the U.S. Government Department or Agency
responsible for pre-publication review.  Failure to comply may result in
rescinding selection for publication and for presentation at the 13th NCS
Conference.

     Technical questions can be addressed to the NCS Conference Committee
through the following means:

            Phone:                   (301) 850-0CSC  [0272]

            Electronic Mail:         [e-mail]

            Government Mail:         National Computer Security Conference
                                       National Computer Security Center
                                       Fort George G. Meade, MD 20755-6000

            Commercial Carriers:     National Computer Security Conference
                                       c/o NCS Conference Secretary
                                       National Computer Security Center
                                       911 Elkridge Landing Road
                                       Linthicum, MD  21090

------------------------------

Date:    Sat, 23 Dec 89 21:38:00 -0500
From:    "Peter S. Graham" <[e-mail]>
Subject: Questions re VIRUS-L

I have two questions which the digest has probably dealt with but for
newcomers might be worth responding to again:

1.  Does the Digest provide a way to query the effectiveness of commercial
antivirus programs against known viruses? --e.g., a kind of table with
commercial (or other published programs) across the top and known viruses
down the side and an X at the intersection if the program handles it.  This
would be a real service.

2.  Does this Digest have a formal feedback mechanism to commercial and other
antivirus program developers, so that they get a sense of what needs to be
done and pronto?  Or do we know that they are all members of the listserv and
we leave it at that, depending on laissez-faire economics?

As a new reader I appreciate the service and the effort that goes into it.

Peter Graham
Associate Vice President for Information Services
Rutgers University / New Jersey

[Ed. To answer 1., there have been various informal product reviews
sent in to the VIRUS-L digest by various readers (perhaps someone out
there has put them together in one doc?) as well as pointers to other
reviews (e.g., PC Mag).

The digest does not offer a formal feedback mechanism.  However,
numerous shareware and commercial anti-virus product vendors to
monitor and (in some cases) contribute to the digest.  Feedback sent
to the digest does reach them.]

------------------------------

Date:    Sun, 24 Dec 89 16:49:07 +0200
From:    [e-mail] (Timo Kiravuo)
Subject: Re: DES Availability

>>For those not aware, the U.S. Government guards the DES formula,

>   Please correct me if I'm wrong, but isn't DES or DES-like
>encryption algorithms readily available?

As far as I understand, the DES formula is public, but exporting
impelemntations is prohibited in the USA. However there is
nothing preventing one to make a DES implementation outside the
USA and distributing it. Here in Helsinki University of
Technology Antti Louko has written one, it is available by
anonymous ftp from kampi.hut.fi (130.233.224.2), file is
alo/des-dist.tar.Z.

It was also posted to USENET comp.sources.??? group a while ago,
the posting was dove via a moderator in Australia, since
importing DES to the is legal by the US law. (Please note that
whatever the US government has to say about DES does not apply to
us outside the US territory, the most USA can do is to contact
our government or send a spy killer or invade Finland like they
did invade Panama.)

As to what this has to do with viruses, I don't know, but I think
that a public DES implementation might be interesting enough to
many people in the virus field, so maybe the moderator will be
nice and let this pass.
- --
Timo Kiravuo
Helsinki University of Technology, Computing Center
work: 90-451 4328, home: 90-676 076
[e-mail]  sorvi::kiravuo  [e-mail]

------------------------------

Date:    Tue, 26 Dec 89 08:17:52 -0500
From:    [e-mail] (David Gursky)
Subject: Re: Virus trends

> To: [e-mail]
> Date: Fri, 22 Dec 89 19:13:24 -0500
> From: [e-mail]
>
> One of the best-known and best researched anti-viral programs for the Amiga
> is VirusX by Steve Tibbetts. A few months ago a new version of this program
> began appearing which was really a trojan. It got rather wide distribution
> before anyone noticed that Tibbetts hadn't really written it. Since that
> time, Tibbetts no longer publishes his source code when he releases a new
> version.
>
> In other words: The prediction you didn't like was really true; it already
> came about!

Oops!  Minor omission on my part.  I neglected to include in my
comment about the authors being well known that they should be easily
and widely reachable!

There is also the underlying presumption in my message that a new
release is confirmed from the author before publication of the
application

------------------------------

Date:    Thu, 21 Dec 89 10:22:00 -0500
From:    [e-mail]
Subject: Comments Attributed to SWE

The following comments indicated by ">" were attributed to SWE in
VIRUS-L 1234.

>SWE first suspected and tested for the public key encryption method
>for several reasons. The major reason was the lack of access people
>outside of the United States would have to the DES encryption formula.

[The DEA is an encryption algorithm developed and licensed by IBM. The
DES is a U. S. Government standard for the implementation of that
algorithm.]

The DES is published and available from The Superintendent of
Documents, U.S.  Government Printing Office Washington, D.C.  It
can be implemented in software without much difficulty.  It is
widely available outside the U.  S.

>For those not aware, the U.S. Government guards the DES formula, and
>software which makes use of this formula may not be exported out of
>the United States. Should it turn out that the DES formula was also
>used, the authors of the AIDS "trojan", could possibly be prosecuted
>under United States statutes pertaining to national security.

While export of any munitions, including cryptography, from the U.S.
msut be licensed, possession or use of the DES or DES outside the U. S.
is not a crime.

>The second reason deals with the DES encryption method. Students of
>cryptology are well aware that the DES formula has been considered
>vulnerable for some time now.

Students of cryptology are aware of an untruth.  While there have
been flawed implementations of the DEA, the cheapest know attack
against the DES is an exhaustive attack against the key.
Such an attack is measured in centuries of 3090 time.

>It is also a well know fact that DES
>specific processors have been produced, which make "cracking" a DES
>encrypted file much easier than the public key method. The DES method
>also limits to a greater degree the length of the encryption key.

Have you seen one?  Do you even know anyone that has seen one?        (Of
course everyone knows someone who knows someone who has seen one, but
that is true of UFO's too.

As to the relative strength of the two method, each is, in part a
function of the key length chosen.  However, in general, public
key lengths of 8 to 10 times as long are required to achieve
comparable security with the DEA.

While the DES limits the length of the key to 56 bits, choice of
key length in an implementation is arbitrary.  IBM sells an
implementation that employs a 112 bit key, if only to protect other
keys.

>Combining these two reasons along with the extraordinary expense the
>authors of the AIDS "trojan" went to, we guessed that they would also
>use a "first class" encryption method.

Very naive analysis.  John McAfee writes:

>    A comparison of the encrypted and unencrypted entries
>indicates that some form of linear character mapping was used
>i.e.     # = I, } = A, 8 = E, @ = D, etc.)

In other words, "first class" equates to a Captain Midnight decoder
ring.  So much for this writer's expert analysis.

William Hugh Murray, Fellow, Information System Security, Ernst & Young
2000 National City Center Cleveland, Ohio 44114
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840

------------------------------

Date:    Thu, 21 Dec 89 15:15:00 -0500
From:    [e-mail]
Subject: AIDS Program (PC)

Does the AIDS program do what it purports to do?  Is that something that
the recipients were interested in having done?  Was it worth $.50 a day?

It is necessary to understand the answers to these questions in order to
know whether we are dealing with:

1) Attempted extortion;

2) A very expensive, obscurely motivated, and otherwise gratuitous
attack;

3) Or, a peculiarly inept attempt to market a program.

William Hugh Murray, Fellow, Information System Security, Ernst & Young
2000 National City Center Cleveland, Ohio 44114
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840

------------------------------

Date:    Thu, 21 Dec 89 15:21:00 -0500
From:    [e-mail]
Subject: Ascii 255

I like the idea of using a non-displayable character to conceal the
presence of a directory.  I also like the idea of using it on the end of
a file name in order to make it hard to establish addressability to the
file.

I like it now almost as much as I did when I first read the idea in the
readers' contributions to PC Magazine.

William Hugh Murray, Fellow, Information System Security, Ernst & Young
2000 National City Center Cleveland, Ohio 44114
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840

------------------------------

Date:    Thu, 21 Dec 89 15:26:00 -0500
From:    [e-mail]
Subject: "Do not use this Diskette"

This advice published in association with the AIDS program is good
advice.

It is a special case of the advice that says use only programs or
diskettes that you expect from trusted sources.

This is a special case of the advice that says do not open mail that has
no return address, is not expected, or is otherwise suspicious.  In a
small number of cases it may be very dangerous to do so.

____________________________________________________________________
William Hugh Murray                     216-861-5000
Fellow,                                 203-966-4769
Information System Security             203-964-7348 (CELLULAR)
                                        ARPA: WHMurray@DOCKMASTER
Ernst & Young                           MCI-Mail: 315-8580
2000 National City Center               TELEX: 6503158580
Cleveland, Ohio 44114                   FAX: [phone]
                                        Compu-Serve: 75126,1722
                                        INET: WH.MURRAY/EWINET.USA
21 Locust Avenue, Suite 2D              DASnet: [DCM1WM]WMURRAY
New Canaan, Connecticut 06840           PRODIGY: DXBM57A
- --------------------------------------------------------------------

------------------------------

Date:    Fri, 22 Dec 89 12:28:00 -0500
From:    [e-mail]
Subject: Spafford's Theorems

In general, I agree with theorems 1, 2, and 3.  I think that those that
deal with the future, are speculative.  However, in the same spirit and
along the same lines, I offer the following:

1. The amount of damage to data and availability done by viruses to date
has been less than users do to themselves by error every day.

2. The press speculation about the DATACRIME virus was much more
damaging than the virus.

3. The amount of damage that has been done to trust within the community
is orders of magnitude worse.

4. Viruses and rumors of viruses have the potential to destroy society's
already fragile trust in our ability to get computers to do that which
we intend while avoiding unintended adverse consequences.

5. We learn from the biological analogy that viruses are self-limiting.

Clinically, if you catch a cold, you will either get over it, or you
will die.  Epidemiologically, a virus in a limited population
will either make its hosts immune, or destroy the population.  Even in
open population, a virus must have a long incubation period and slow
replication in order to be successful (that is, replicate and spread).

6. The current vector for viruses is floppy disks and diskettes, not
programs.  That is to say, it is the media, rather than the programs,
that are moving and being shared.

A virus that is stored on such media will be very persistent.  One
infected diskette pulled from a drawer may began a new cycle.

On the other hand, diskettes as media have a limited life expectancy.
Punched paper lasted just a century; 8.5" floppies only a decade.  The
life of such media is a function of a number of complex factors.  The
success of the current technology augers for a long life, while the pace
of technology suggests that it will be short.

7. AIDS not withstanding, terrorists have more effective and efficient
mechanisms at hand.  Amateurs have a very high vested interest in a
community in which programs can be relied upon to do only what they
advertise.  It is to be hoped that they can be socialized not "to soil
their own sandpiles."

Season's Greetings.

William Hugh Murray, Fellow, Information System Security, Ernst & Young
2000 National City Center Cleveland, Ohio 44114
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840

------------------------------

Date:    Mon, 25 Dec 89 19:45:47 -0800
From:    [e-mail]
Subject: Re: Virus Trends

     Back in the 1970s, when I was working on secure operating systems,
I never dreamed that the day would come when there would be twenty five
million computers in the world running without memory protection.

     And it's going to get worse.  New and interesting programmatic objects
are coming into being.  Attacks need not be through object programs.
Already, there have been attacks via mail, and via text files editable by
GNU EMACS.  But this is just the beginning.

     - PostScript is a programming language.  Trojan horses could be
       embedded in PostScript files.  While attacking a printer isn't
       all that productive, Display PostScript offers more tempting
       targets.

     - A FAX message is a bitstream interpreted by an interpreter at
       the receving end.  Could it be induced to do something interesting
       through the use of illegal bit patterns?  Group III is probably too
       simple to be attacked, but group IV?  Imagine a message which
       causes a FAX machine to send an extra copy of transmitted documents
       to another location.

     - Network transmittable C++ objects are being developed.  Security
       doesn't seem to be mentioned.  This has promise.

     - Multi-media electronic mail offers new avenues of attack.

The basic problem is that the transmission of programmatic objects is
on the increase, and anything interpreted at the receiving end is
potentially a means of attack.  I predict that this will grow to a
moderately serious problem in the 1990s.

                                        John Nagle

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Friday, 12 Jan 1990    Volume 3 : Issue 10

Today's Topics:

WISE Data Systems shipping STONED infected PC's
Re: Shrink Wrap...still safe?
Desktop Fractal Design System Virus (PC)
1812 Virus (PC)
AIDS trojan questions (PC)
Re: Implied Loader Viruses (Mac)
Re: Shrink Wrap...still safe?

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

---------------------------------------------------------------------------

Date:    Thu, 11 Jan 90 13:36:00 -0330
From:    [e-mail]
Subject: WISE Data Systems shipping STONED infected PC's

Hi. Hope this is relevant to this list ...

We've discoved that the driver diskette shipped with a Wise Data Systems
PC is infected with the STONED virus. The system has a tgva VGA card and
OAK software on a Wise 386/25

------------------------------

Date:    Thu, 11 Jan 90 11:39:41 -0800
From:    well![e-mail] (Michael Odawa)
Subject: Re: Shrink Wrap...still safe?

> we have been using a rule of thumb to stick to shrink wrapped software
> to help avoid viruses.  What comments &/or advice do you have for this
> situation?

Both shrinkwrapped and downloaded software sources have their
advantages and risks of contamination.  It is our belief that the
important factor is not the distribution method by which you acquire
your software which will protect you, but the integrity of your
sources.  While there have been some very serious and regrettable
instances of viruses appearing in both shrink-wrapped and downloaded
software, these are rare in comparison to the viral propagation that
results from software that is "passed around."

To achieve maximum protection you should (a) acquire software only
from trusted sources, (b) scan and monitor your system for viral
activity regularly, and (c) backup often and systematically.

Michael Odawa
Virus Task Force
Software Development Council
[e-mail]

------------------------------

Date:    Thu, 11 Jan 90 17:33:23 -0000
From:    [e-mail]
Subject: Desktop Fractal Design System Virus (PC)

As one of the "mugs" (probably translates as "schmuck" stateside?) who
ran the Desktop Fractal Design System as soon as it arrived, can I ask
any genius out there who works out how to get rid of it to contact me
pronto?

However I have checked the size of my .EXE files against copies on other
machines and I get identical results, plus VIRUS SCAN does not detect
any infection. Could it be that not all the disks were infected, or
only those distributed in the USA?

Rgds,
Iain Noble
- -----------------------------------------------------------------------------
Iain Noble                                   |
[e-mail]                           |  Post:  Main Site Library,
JANET: [e-mail]                    |         Teesside Polytechnic,
EARN/BITNET: LBA002%pa.tp.ac.uk@UKACRL       |         Middlesbrough,
INTERNET: [e-mail] |         Cleveland, UK, TS1 3BA
UUCP: [e-mail]            |  Phone: [phone] x 4371
- -----------------------------------------------------------------------------

------------------------------

Date:    Thu, 11 Jan 90 17:04:38 -0500
From:    [e-mail]
Subject: 1812 Virus (PC)

Earlier today we found out that SHRINK-WRAPPED software called The
Desktop Fractal Design System by Michael F. Barnsley, Iterated
Systems, Inc. (1989) is infected with a virus.  The program is sold
through Academic Press and they are aware of the problem.  VIRSCAN
(the IBM product) identified it as the 1813 virus.  Seems the EXE and
COM files run since the offending software was loaded were all
clobbered and their filesizes grew exponentially every time they were
loaded.  Interestingly enough, none of the network files were
affected.  Was it was pure luck or that the file attributes on the
network COM & EXE files were set to READ ONLY?  Oh, where's the
aspirin !?  Anyway, could somebody do a quick review of the atrocities
which will befall us with the 1813 virus? Thanks.

  Mignon Erixon-Stanford, PROFS & LISTSERV Administratress
  Smithsonian Institution, Washington, DC.
  IRMSS907 @ SIVM

------------------------------

Date:    Thu, 11 Jan 90 20:06:44 -0500
From:    [e-mail]
Subject: AIDS trojan questions (PC)

Now that the dust has settled a bit, does anyone know how much damage
was really done by the AIDS trojan?  Also, has anyone come up with a
good explanation of why it was released in the first place?

Jim Blakley

------------------------------

Date:    Thu, 11 Jan 90 22:50:24 +0000
From:    biar![e-mail] (Robert J Woodhead)
Subject: Re: Implied Loader Viruses (Mac)

[e-mail] (Joe McMahon) writes:

>Any resource which appears to be of an executable type which is found
>in a "non-application" file will be flagged as an "implied loader".

I think this is VERY dangerous.  How do you define what an
"executable" file is?  How about a Hypercard Stack?  It is quite
possible for a document to have a legal "executable" resource, and any
false positive is going to result in the trashing of someone's data.

- --
Robert J Woodhead, Biar Games, Inc.   !uunet!biar!trebor | [e-mail]
Announcing TEMPORAL EXPRESS.  For only $999,999.95 (per page), your message
will be carefully stored, then sent back in time as soon as technologically
possible.  TEMEX - when it absolutely, postively has to be there yesterday!

------------------------------

Date:    Fri, 12 Jan 90 04:27:09 +0000
From:    [e-mail] (Ben Liberman)
Subject: Re: Shrink Wrap...still safe?

[e-mail] (Craig W. Fisher) writes:
>At a meeting yesterday some people made comments that some viruses
>have been found in shrink-wrapped diskettes.  This did surprise me as
>we have been using a rule of thumb to stick to shrink wrapped software
>to help avoid viruses.

A problem that may show up with shrink warped (sic) software is that sometimes
retailers will take back software from customers, and re-shrink warp it, at the
store.  If the customer tried the software out on an infected machine....

- --
        ------------    ------------   ----------------------
        Ben Liberman    USENET         [e-mail]
                        GEnie,Delphi   MAGIK

------------------------------

End of VIRUS-L Digest
*********************
VIRUS-L Digest   Monday, 15 Jan 1990    Volume 3 : Issue 11

Today's Topics:

Possible New Infection (Mac)
Re: Shrink Wrap...still safe?
Re: Shrink Wrap...still safe?
IBM's VIRSCAN and the 1813 virus (PC)
Implied Loading and Accidental Destruction (Mac)
Re: virus scanning
WDEF and Virus Detective 3.0.1 (MAC)
An unfortunate victim (Mac)
Organizational attitudes about virus prevention
WDEF virus (Mac) in southwestern Ohio
RE: Shrink wrap...still safe?
Re: Shrink Wrap...still safe?
Shrink-Wrapped Software
F-PROT clarification (PC)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

---------------------------------------------------------------------------

Date:    Fri, 12 Jan 90 07:49:47 -0500
From:    "Gregory E. Gilbert" <[e-mail]>
Subject: Possible New Infection (Mac)

I saw this posted in Vol. 8, Number 6 of the INFO-MAC Digest.  THought is was
worthy of a cross posting.

Date: Tue, 9 Jan 90 15:22 EST
From: [e-mail]
Subject: Trojan Horse???? A new one

I recently saw a posting about two new sharewares, JCremote and Mac II
Diagnostic Sound.  After unBinHexing and Unstuffing them, I did what most of
would, I checked for viruses using SAM Virus Clinic 1.3.  No known viruses were
detected.  I tried the Mac II Diagnostic Sound and then installed JCremote.  As
I installed JCremote into my system folder SAM 1.3 warned me about attempts to
modify the system file, however, this is not uncommon with a CDEV or RDEV.
After installing it, I opened the chooser and selected JCremote.  The system
froze.  When I rebooted the computer the computer started to launch, but the
crashed.  There was no bomb or any message, just a blank screen.  After
rebooting with a floppy and checking with Disinfectant 1.5, the system file was
noted as having a damaged resource fork.  This meant I had to install a new one
.

I am not sure which of the two mentioned files are the culprit.  The first time
it happened I heard a sound which sounded like one of the Mac II Diagnostic
Sound sounds and the freeze occurred when I tried running JCremote.

Rich
Friedman@biovax

Greg

Postal address: Gregory E. Gilbert
                Computer Services Division
                University of South Carolina
                Columbia, South Carolina   USA   29208
                [phone]
Acknowledge-To: <C0195@UNIVSCVM>

------------------------------

Date:    12 Jan 90 09:14:40 -0500
From:    [e-mail] (Earle Ake)
Subject: Re: Shrink Wrap...still safe?

[e-mail] (Craig W. Fisher) writes:
> At a meeting yesterday some people made comments that some viruses
> have been found in shrink-wrapped diskettes.  This did surprise me as
> we have been using a rule of thumb to stick to shrink wrapped software
> to help avoid viruses.  What comments &/or advice do you have for this
> situation?
>        Thanks, Craig

          If you have a virus on your system that reproduced your master
diskette, that virus could infect the copy.  If the store that
re-sells your software takes off the shrink-wrap, tests the program
and re-shrink-wraps it, there is a chance of a virus infecting it
there.  If someone buys a package, takes it home and discovers it will
not work on his system and returns the software, the store
re-shrink-wraps it and sells it for new.  Yet another way to infect a
disk even though it was sold 'shrink-wrapped'.  Do we have to put all
software in tamper-resistant packaging like Tylenol?  If a store tries
a package out so they can be able to tell customers how good it is,
can they sell that diskette as new software still?  Do we have to
demand a no-returns policy on software?  Hey, the customer might have
a shrink-wrap machine available to them and would be able to
shrink-wrap and return as new.  Where do we draw the line?
Shrink-wrap doesn't mean virus-free!
 _____________________________________________________________________________
             ____ ____    ___
 Earle Ake   /___ /___/ / /     Science Applications International Corporation
           ____//   / / /__                 Dayton, Ohio
 -----------------------------------------------------------------------------
 Internet: [e-mail]    uucp: uunet!dayvb!fac2

------------------------------

Date:    12 Jan 90 15:09:31 +0000
From:    [e-mail] (Gene Spafford)
Subject: Re: Shrink Wrap...still safe?

Many large retailers (and some wholesalers) have shrinkwrap machines.
They use these to rewrap packages of software that endusers may have
purchased and then returned.  They may also rewrap software packages
that they have been using in-house as demo programs.  They usually do
not check the diskettes to see if they have been modified with a virus
or other nasty.  The purchaser usually has no way of knowing if the
package they have just purchased has been rewrapped in this manner.

Additionally, there have been some commercial distributions shipped
with a virus on the diskettes.  Usually, this contamination occurs in
the stages where the diskette is formatted or copied, not when the
master copy of the software is produced.  That is, the machines doing
the copying are infected and they introduce the infection when they
copy the master version onto the diskette.  Most software houses are
now aware of this problems and they take greater care to protect
the machines used to produce the distribution.

Words of advice:
   Get in the habit of using virus scan programs on EVERY new diskette
   you add to your system.  It will only take you a few extra minutes
   but may save you a great deal of trouble.  Establishing the habit
   is very good practice.  Keep a virus monitor (e.g., Gatekeeper,
   FluShot+) installed on your system and activated just in case.

   Point out to your retailer/wholesaler that should you ever buy a
   product from them with a virus on it, introduced because they have
   re-wrapped an infected product, they are liable for damages in a
   lawsuit.  Encourage them to label any package so rewrapped -- then
   be extra careful when purchasing same.

- --
Gene Spafford
NSF/Purdue/U of Florida  Software Engineering Research Center,
Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-2004
Internet:  [e-mail] uucp:     ...!{decwrl,gatech,ucbvax}!purdue!spaf

------------------------------

Date:    12 Jan 90 00:00:00 +0000
From:    "David.M..Chess" <[e-mail]>
Subject: IBM's VIRSCAN and the 1813 virus (PC)

The 1813 virus is sometimes referred to (here, in the news, etc)
as the "Jerusalem" virus.  So if VIRSCAN says you have the 1813,
information about, and disinfectors for, the Jerusalem virus
are appropriate...          DC

------------------------------

Date:    Fri, 12 Jan 90 09:33:36 -0500
From:    Joe McMahon <[e-mail]>
Subject: Implied Loading and Accidental Destruction (Mac)

Bob Woodhead noted the distinct possibility that a useful resource in a
"non-application" file could be accidentally trashed by GateKeeper Aid
or a similar program which kill executable resources.

First, I assume that Chris J. was careful enough to include a list of
"don't do that to this file type/creator" entries (I can't check today,
my Mac's dead :-( ), or maybe a list of file types that should NOT
contain executable code resources.

I think the *idea* is good; I'm sure that he put more thought into
the implementation than I did in my glib oversimplification of its
functions. I was just trying to explain why it was that the ADBS
resources were being trashed by GK Aid.

For those who may have missed the beginning of all this, GK Aid
will kill off code resources (and WDEF, PACK, etc. executables)
in files in which they "don't belong". Deciding what "doesn't
belong" is, of course, the kicker. Bob is very right about the
possibility of damage to "non-standard" files.

 --- Joe M.

------------------------------

Date:    Fri, 12 Jan 90 09:53:42 -0500
From:    Eric Roskos <[e-mail]>
Subject: Re: virus scanning

> I am told that in the November '89 issue of the American Mathematical
> Monthly, to the effect that no completely safe computer virus test is
> possible.  The proof is suppose to be short, and along the lines of
> the various proofs of the Halting problem.

Of course.  Just replace the "halt" instruction with a sequence of code
to insert a virus (or to perform any malicious action).

The approach to addressing the problem of viruses is not to automatically
analyze code, but rather to prevent the propagation of viruses.

This aside, turning to what I'd intended to say when I started this
reply (I get easily sidetracked by computing theory :-)):

> The Desktop Fractal Design System by Michael F. Barnsley, Iterated Systems,
> Inc. (1989) is infected with a virus.

This surprises me, since I bought a copy of this program at Reiter's
Scientific Bookstore in Washington DC last November, and used it on my
PC for a couple of days (before getting inspired by it to write my own
programs...  some of his algorithms he gives in the manual are really
hard to figure out, since he's optimized them for integer arithmetic and
he doesn't show all the simplifications he did, only the final
result)...  since then I have used the PC everyday, and have run one of
the virus-checking programs on it several times, without any indication
of a problem! Does anyone have details on which particular virus this
is, or what is added to the end of the object files that one can check
for? I'll run the virus-checking program on the disk itself this evening
to make sure, but from the (very limited) evidence it looks like either
not all the copies of the program are infected, or this is not one of
the standard viruses.

------------------------------

Date:    Fri, 12 Jan 90 13:35:15 -0500
From:    [e-mail]
Subject: WDEF and Virus Detective 3.0.1 (MAC)

Hi,

     This past week we have had numerous infections of WDEF A.

     I noticed some odd behavior by Virus Detective 3.0.1

1) Open Virus Detective and select 'autocheck disk on insertion'

2) Insert a diskette known to be infected with WDEF A

3) When the scan detects the virus, click Continue to finish the
   scan.  Now drag the disk to the trash to eject it.  The diskette
   will remain infected until the desktop is rebuilt on it.  The hard
   disk is untouched, though.
      If, however, instead of clicking Continue, you click Cancel
   and eject the disk in the same manner, the virus immediately
   infects the hard disk.

Any one else had this problem?

                       Andy Wing
                       Senior Analyst
                       Temple University School of Medicine

------------------------------

Date:    Fri, 12 Jan 90 14:30:03 -0500
From:    [e-mail] (David Gursky)
Subject: An unfortunate victim (Mac)

The latest MacWeek (9 Jan) has an article on page 10 that describes
the latest victim of the problem of electronic vandalism.

1st Aid Software, publisher of Anti-Virus Kit (which recently acheived
notoriety as being the only Mac Anti-virus application that
effectively detected and prevented WDEF *before* WDEF was isolated)
has announced they will issue no further updates to the application.
Their line of reasoning is the same as Don Brown's for not updating
Vaccine.  1st Aid does not wish to get into an ever escalating battle
of more sophisticated tools s. more sophisticated threats.

I'm sorry to see this happen.  While I believe we are essentially
fighting a "staying effort" with vandalism today, walking away from
the problem will not stop the continuing evolution of electronic
threats.

------------------------------

Date:    Fri, 12 Jan 90 12:09:00 -0800
From:    [e-mail] (JAMES E. MOLINI)
Subject: Organizational attitudes about virus prevention

Jeff Spitulnik writes:
>  What should be done to rid UM of the WDEF virus or of any virus for
>that matter?  How does the bureaucracy at your institution handle it?
>I question the ethicality of a laissez-faire attitude on viruses at
>any institution.

Although I agree with Brian McMahon's response (Virus_L 9 Jan 90) that:

> KNOWINGLY allowing unsuspecting users to contract infections is
> EXTREMELY irresponsible.

I think there is a more subtle problem here.

If U. Mich is like most universities, they place a great deal of emphasis
on COOP work terms and Summer Faculty Research programs at government
agencies and corporations around the US.

Since most of these people bring their own programs and utilities along
with them, a laissez-faire attitude toward viruses is like not doing
anything about head lice.  It may be easy to do at home, but can be
embarrassing if you go some place else.   Once these people get to their
prospective sites and infect a few computers, they may find that their
sponsors are unwilling to take a similar risk next year.

I can say from experience that the cost of eradicating a virus at a large
research facility usually costs more than the money spent sponsoring the
faculty fellow, or coop.  Therefore, even though no one may directly say
so, the amount of problems you cause with a naive attitude about computing
could have a bearing on whether, or not you are invited back.  (Please
don't take this thought out of context and try to flame on me for it.)

Something any university should be concerned about is the concept of "Guilt
by association."  I have listened to several people who used to
(incorrectly) associate Lehigh University with virus problems.  Fortunately
Lehigh is now developing a reputation for their efforts in the area of
virus control.  But I think you understand the point.

Now, there are a few minor guidelines that anyone can follow to reduce
their chance of taking viruses, or malicious programs with them when they
travel.  Although the methods are not foolproof, they should reduce the
risk to a more acceptable level.

1.  Don't bring bootable floppies with you when you go to a new job.  There
    is usually no need to boot someone else's machine from your floppy and
    it will go a long way toward stopping boot infector viruses.

2.  If you have written programs to use while you are there, bring the
    source code and recompile your programs at the new location.  It is a
    reasonable way to prevent viruses and will avoid problems you may have
    with OS version differences.

3.  If you use public domain software, try to download copies from the
    Organizational BBS at your new location, if they have one.  Most large
    institutions today have a designated BBS system which is frequently
    checked for viruses and malicious programs.  And if you find that you
    are infected anyway, at least you know where you got the software from.

4.  If you must bring executable code with you, ask your sponsor if there
    is a procedure for checking software that comes in.  Usually this
    function is centralized and associated with other help functions that
    you will probably need in the future.  Anyway, by asking, you will show
    yourself to be a knowledgeable and concerned user.

5.  NEVER bring pirated software with you when you go to the new location.
    There is nothing worse than finding out that someone infected your site
    with a piece of software that they weren't supposed to have in the
    fist place.  Most large organizations already have all the software you
    should need and have huge software investments to protect.  Prudent
    organizations would see this as cause for immediate dismissal.

I hope this helps.

Jim Molini

------------------------------

Date:    Fri, 12 Jan 90 16:44:38 -0500
From:    Joe Simpson <[e-mail]>
Subject: WDEF virus (Mac) in southwestern Ohio

Miami University in Oxford,Ohio has been visited by the WDEF virus.

An instance was detected and eradicated with GateKeeper Aid 1.0.1.

------------------------------

Date:    12 Jan 90 19:34:00 -0400
From:    "WILLIAM HADLEY" <[e-mail]>
Subject: RE: Shrink wrap...still safe?

Craig,
   When you buy software in a computer store that is shrink wrapped, it may
not have always stayed in that condition before *you* bought that software.
There are software stores (at least in the Washington, D.C. area) that will
re-shrink wrap software packages when they are returned.  For example, if
someone bought a software package, took it home, and didn't like it.
They could take it to the software store who would take the software back
as long as the software still had the documentation AND the registration
card.  They would take the software and offer an exchange or refund and send
the customer on his/her way.  Then the store would take the software into
the backroom and procede to re-shrink wrap the software and put it back on
the shelf.  I (as the customer) had an experience like this.  I returned a
piece of software that I was not what I thought.  The store I bought it from
was more than happy to assist me (keep the customer happy).  They asked if
everything that came in the box was there, which of course it was.  Then the
sales clerk SPECIFICALLY asked me if the registration card was in the box.
Again, I assured him that everything was there.  He explained that he had to
ask about that because they were going to put it back on the shelf and re-sell
the package.  I asked if he could sell it without the shrink wrap on the box,
to which he replied, "Nah, we have a shrink wrap machine in back" (not
necessarily a direct quote).  I thought about that, about specifically asking
for the registration card.  I could have pirated the software and sent in the
card as though I *actually* paid for it.   But then  I thought a little bit
more about the whole transaction.  The clerk never looked in the box when I
was standing there to see if everything was in it.  After refunding my money,
he took the box in back, wrapped it, and brought it back before I left the
store.  He could have looked while he was in back, but I don't think he did
because he was not gone for very long.  Also, he never asked to see a sales
recipt.  There was no price tag on the box (it was shrink wrapped when I bought
it and the tag was stuck to the wrapping which I threw away) so he wouldn't
have known for sure if I even bought it at his store - if I bought it at all.
I could have stolen the software, pirated it and get *my* money back.  Or I
could have stolen the software, INFECTED it, and then get *my* money back.
The store and the software company would have never known - neither would the
unsuspecting customer who might have bought that software.

**JUST FOR THE RECORD**
I *did* pay for it, and I *did* have my sales recipt with me when I returned
the software.  I was *not* satisfied with the program.  And, I did *not*
pirate it and did *not* infect it with anything.

------------------------------

Date:    14 Jan 90 01:45:42 +0000
From:    [e-mail] (Woodrow Baker)
Subject: Re: Shrink Wrap...still safe?

I applogize for posting this here, but my mailer would not
let me reply to someone who replied to a message I posted here.
siia!drd:

          Postscript fonts are executable files.  Like any other postscript
program they have file access, and full unfettered access to the system.
They are for the mostparts, encrypted, but the encryption and decryption
algs are known.  A malicious person could create a font program that could
when run, delete all files off the hard disk, or more viciously, subtly
alter existing fonts from say Adobe, or some other font company.  They
could be altered to do more than just print funny.  They could clear the
page, print messages over pages, corrupt the filesystem (very easy to do
by the way, and in general create all manner of havoc.

The posiblilty is very real.

Cheers
Woody

------------------------------

Date:    Sun, 14 Jan 90 18:02:00 -0500
From:    [e-mail]
Subject: Shrink-Wrapped Software

>At a meeting yesterday some people made comments that some viruses
>have ben found in shrink-wrapped diskettes.  This did surprise me as
>we have been using a rule of thumb to stick to shrink wrapped software
>to help avoid viruses.  What comments &/or advice do you have for this
>situation?
>       Thanks, Craig

Shrink wrapping is a form of encapsulation that reduces the risk that
software will be contaminated and increases the probability that
tampering will leave evidence.  The vendor of software has an interest
in an orderly market place and in the reputation of his product.  If you
have evidence that the product has not been tampered with since the
vendor shipped it, then you may rely, in part upon his interests.

Shrink-wrap that is applied by the vendor would help to serve that
purpose.  However, few original vendors use labelled shrink-wrap and
many distributors and retailers can apply shrink wrap.

Since much software is poorly labelled, since it is hard to demonstrate,
and generally difficult to buy, Many retailers have adopted a
"Trial/Return" policy.  Under this policy a purchaser is permitted to
return software  for a full refund within a limited period of time.  The
retailer re-wraps the software and returns it to the shelf.  Most such
retailers are simply naive, a few are irresponsible.

The risk to the retailer is that the "purchaser" will simply make a copy
of the software and return the original media and documentation to the
retailer.  However, the retailer can measure this risk.  The risk to
subsequent purchasers of the used package is that the media was
contaminated before it was returned.  This risk is harder to measure and
is not to the person making the decisions.

Vendors can help by using labelled shrink-wrap.  To the extent that
users come to expect such labelling, the re-wrap strategy becomes less
effective and efficient for the retailer.  Users can protect themselves
and discourage this risky practice by refusing to deal with retailers
that offer them the right to return.

William Hugh Murray, Fellow, Information System Security, Ernst & Young
2000 National City Center Cleveland, Ohio 44114
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840

------------------------------

Date: Mon, 15 Jan 90 12:16:31 GMT
From: [e-mail] (Fridrik Skulason)
Subject: F-PROT clarification (PC)

Since I made the F-PROT package available, I have received a
considerable number of messages containing the same questions over and
over.

So, here is an attempt to clarify a few details:

        When new viruses appear, you do not have to obtain a new version
        of the program. It is only necessary to add a single line to a
        file. This line contains an encrypted signature string with a
        checksum. The programs will then be able to find any infections
        by the new viruses.

        I will create this line and post it here on VIRUS-L/comp.virus.

        However, you need a new version of the program if you want to
        disinfect a program infected with any of those new viruses.
        I have to write a disinfection routine for each virus - a task
        that sometimes takes as little as five minutes, but in other cases
        a full day of work.

        The tiny (2K) .SYS file that prevents the execution of any infected
        program must also be updated to stop new program viruses.
        It should, however, be able to detect any new boot sector viruses
        without changes.

        The list of viruses the program can handle ...

                Agiplan, Alabama, Alameda (Yale), Amstrad, April 1., Brain,
                Cascade, Dark Avenger, DataCrime, DataCrime II, dBase,
                December 24th, Den Zuk/Ohio, Disk Killer (Ogre), Do-Nothing,
                405, 4096, Fumble, Fu Manchu, Ghost, Icelandic/Icelandic II/
                Saratoga, Jerusalem/New Jerusalem/Sunday, Lehigh, MIX1,
                New-Zealand (Stoned), Oropax, Perfume, Ping-Pong/Typo,
                South African "Friday 13.", Sylvia, SysLock/Macho, Swap
                (Fallboot), Traceback/2930, Vacsina, Vcomm, Vienna/Lisbon,
                Virus-90, W13, Yankee Doodle and Zero Bug (Palette)

        ... does not quite match other lists of known viruses, but in most
        cases this is because different names are used for the same virus.
        There are, however, a few viruses that have been reported but not
        made available for research. They are obviously not included (yet).

        The documentation includes a description of all the viruses, even the
        most recent ones like Amstrad, Perfume, Virus-90, W13 and Vcomm.

        The suggested contribution of $15 is for a single copy - for an
        organization which uses the program on more than one machine, the
        suggested contribution is $2 for each additional copy.

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Tuesday, 16 Jan 1990    Volume 3 : Issue 12

Today's Topics:

Re: Shrink-Wrapped Software
Some more thoughts on shrink-wrapped software...
Re: RE: Shrink wrap...still safe?
Protecting software from contaminatation
AFD Listserv that has SCANVx.arc (PC)
Internet worm writer to go to trial Jan 16th. (Internet)
WDEF in Ireland (Mac)
Re: Shrink-Wrapped Software
Biological analogy source requested

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

---------------------------------------------------------------------------

Date:    Mon, 15 Jan 90 08:33:19 -0500
From:    Brian Piersel <[e-mail]>
Subject: Re: Shrink-Wrapped Software

On Sun, 14 Jan 90 18:02:00 -0500 <[e-mail]> said:
>Vendors can help by using labelled shrink-wrap.  To the extent that
>users come to expect such labelling, the re-wrap strategy becomes less
>effective and efficient for the retailer.  Users can protect themselves
>and discourage this risky practice by refusing to deal with retailers
>that offer them the right to return.

Another way vendors can help is to sell software on write-protected
diskettes. I always (or almost always) write-protect the master
diskette before putting it in the disk drive, to insure that nothing
happens to my original, anyways. This would also prevent the disk
from being infected.

+----------------------------------------------+
|  Brian Piersel                               |
+----------------------------------------------+
| BITNET:  SPBK09@SDNET                        |
| INTERNET:  [e-mail] |
+----------------------------------------------+
| IBM = Itty Bitty Machine                     |
+----------------------------------------------+

------------------------------

Date:    Mon, 15 Jan 90 12:00:43 -0500
From:    [e-mail] (David Gursky)
Subject: Some more thoughts on shrink-wrapped software...

What is really most amazing about the problem of a potential vandal infecting
a commercial application, and returning it to an unsuspecting vendor is the
ease with which the vendor can detect the problem.  Consider the following
scenario:

1 -- An application is returned to a vendor.

2 -- Proof of purchase is produced, vendor agrees to accept product, but does
     not yet refund purchase price.

3 -- A second copy of the shrink-wrapped application is removed from the
     shelf.

4 -- The disk(s) from the returned copy are then byte-by-byte compared against
     the disk(s) in the shelf copy from step 3.

5 -- If no major changes are found (some users still run the applications
     straight off the master disk, and some of those applications modify them-
     selves in some minor fashion), the consumer's money is then (and only
     then!) refunded.

     If major problems are found, perhaps only a portion of the purchase price
     is refunded, or none at all, depending on how the store wishes to actually
     implement the procedure.

Likewise, an office that purchases multiple copies of an application can
perform a similar function on incoming shrink-wrapped software.  A direct copy
(especially when done at a machine that is "clean") should be very effective
at uncovering vandalized software.

------------------------------

Date:    15 Jan 90 16:42:17 +0000
From:    [e-mail] (Leonard P Levine)
Subject: Re: RE: Shrink wrap...still safe?

Many vendors are now selling software on un-notched disks.  My most
recent copy of wordstar, my copy of spinrite and even one shareware
product have come to me on disks that cannot be written to except with
modified computer hardware.

Such software can only be infected at the factory, and the probability of
that is becoming increasingly small.

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Leonard P. Levine                  e-mail [e-mail] |
| Professor, Computer Science             Office [phone] |
| University of Wisconsin-Milwaukee       Home   [phone] |
| Milwaukee, WI 53201 U.S.A.              FAX    [phone] |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

------------------------------

Date:    Mon, 15 Jan 90 12:02:02 -0500
From:    Peter Jones <[e-mail]>
Subject: Protecting software from contaminatation

On Sun, 14 Jan 90 18:02:00 -0500 [e-mail] said, in
VIRUS-L Digest   Monday, 15 Jan 1990    Volume 3 : Issue 11:
>Subject: Shrink-Wrapped Software
>
>Shrink-wrap that is applied by the vendor would help to serve that
>purpose.  However, few original vendors use labelled shrink-wrap and
>many distributors and retailers can apply shrink wrap.

If vendors used read-only diskettes, contamination of the distribution
diskettes would become almost impossible for casual users. The user would have
to tamper with the write-protect switch on his diskette reader to allow
alteration of a diskette.
Early Apple-IIs are the only machines I know of in which diskette write
protection can be overcome by software.

Peter Jones     MAINT@UQAM     (514)-987-3542
"Life's too short to try and fill up every minute of it" :-)

------------------------------

Date:    Mon, 15 Jan 90 15:35:00 -0500
From:    <[e-mail]>
Subject: AFD Listserv that has SCANVx.arc (PC)

        HI!

                I have learned of the AFD feature on listserv. I was wondering
       if there is a site that has it setup in such a way that i can get
       SCANVxx.arc as an afd. I've tried rice but the server there only
       has it as part of the simtel20 archives. (and those you must use
       special /pdget type commands for) Also, I don't think you can specify
       wildcards on an afd so how would we get the latest version of scan.

        I'm sure others would be interested in doing this!

        Please send a copy of any replies to me direct as I don't subscribe
        to this list. (too much volume)

        Thanks!

                Jeffrey Perry
                Computer Science Student
                Northeastern University Boston, ma
                [e-mail]

------------------------------

Date:    16 Jan 90 03:47:00 -0500
From:    "Damon Kelley; (RJE)" <[e-mail]>
Subject: Internet worm writer to go to trial Jan 16th. (Internet)

        I just wanted to inform the readers of this list that Robert
T. Morris of Arnold, Maryland is going to trial this January 16, 1990
for unleashing (was it "The Great Internet Worm?") a worm that
immobilized a certain computer network in November of 1988.  Mr.
Morris is a student who was suspended from Cornell University because
of his actions.

        When I read the article that I got the above information from,
I was a bit shocked that the jurors were deliberately picked by the
U.S. Justice Department lawyers because didn't know *anything* about
computers.  Would the jurors understand enough of the computer talk
thrown between defense and prosecutor to reach a truly informed
verdict?

        My mother and I discussed the issue.  I said that the trial
would be unbalanced and handled badly because every little techie term
would have to be explained over and over again to the jury, slowing
down the trial process.  Isn't a "jury of his peers" called for here?

        She said that the trial would be more impartial if the jury is
composed of non-tech persons.  Comments?

        Does the Justice Department have a prejudice against computer
enthusiasts?  Perhaps so.  In the article I read, the lawyers excluded
persons who owned computers, but included persons whose jobs involved
"pushing buttons," such as flight reservation clerks and insurance
claim processors.

        Those lawyers better straighten up.  Not all computer
enthusiasts practice regularly what Mr. Morris did, nor do they openly
encourage the wanton destruction of computer systems "for a kick."

Source: _The_Baltimore_Evening_Sun_, January 15, 1990. Section D, top
of page 2: "'Illiterates' Judging Computer Genius."  The information
in the first two paragraphs is selected bits, not direct quotes, so
don't bother to flame me.

DISCLAIMER:
        The information above does NOT represent the views of any
organization, group, man, woman, beast, insect, microbe, matter,
energy, etc. existing in all the planes of reality known/not known!
To assume that this information is more than the sputterings of the
author is stupidity on your part.

Damon (@umbc.bitnet) (@umbc2.umbc.edu) ([e-mail] [uucp.  Guess a
path...] )

------------------------------

Date:    16 Jan 90 10:06:52 +0000
From:    Colman Reilly <[e-mail]>
Subject: WDEF in Ireland (Mac)

The WDEF virus has been reported in Trinity College, Dublin - I don't
have details but the needed anti-viral stuff is available - Thanks to
all involved in producing the software.

-
 -------------------------------------------------------------------------------
[e-mail]                   Colman Reilly
All my own work-no one else has any claim or responability for my opinions
-
 -------------------------------------------------------------------------------

------------------------------

Date:    Tue, 16 Jan 90 11:17:59 +0000
From:    [e-mail] (P E Smee)
Subject: Re: Shrink-Wrapped Software

In article <[e-mail]> [e-mail] wr
ites:
>Vendors can help by using labelled shrink-wrap.  To the extent that
>users come to expect such labelling, the re-wrap strategy becomes less
>effective and efficient for the retailer.  Users can protect themselves
>and discourage this risky practice by refusing to deal with retailers
>that offer them the right to return.

Two points here:  The first is (far as I know) unique to the UK.  We
virtually never SEE shrink-wraps.  The reason is that (allegedly to
prevent theft) the software shops display only the empty boxes on their
shelves.  The contents are removed to be stored behind the counter, and
are replaced in the box when you buy the software.  (Yes, it
occasionally causes problems.  My copy of Dungeon Master turned out to
include a Falcon registration card.  Sigh.) For big-selling software
(read, popular games) they will probably also have some unopened boxes
behind the counter; but for more serious stuff, the opened copy is
probably the only one they've got.  And, you can't just take your
business elsewhere, because they all do this.  (Records, prerecorded
cassettes, CD's, and videotapes are all also marketed this way.)

Second problem is more general, in that you are also thereby more or
less guaranteeing that the retailer will not be willing to demo a
package to you before you buy it.  For a lot of packages, particularly
the serious (and expensive) ones, you can't really tell from the
manufacturers' puff whether the product will do what you need -- or,
indeed, anything useful at all.  Again, for popular products this might
be eased, but for things with a limited market -- well, the dealer is
hardly going to invest in a separate demo copy of something which only
sells a copy a month or so.

What's really needed is some way that the maker can include, separate
from the disk, some form of 'signature' which can be used with a
publicly available verification program, so that you could scan the
disk with the verifier, and compare the output with the provided
signature.  Akin to a checksum, but sufficiently complex that any
change to the disk would be detected.  (There's a thesis topic for the
next 10 years' worth of Masters candidates. :-)  The problem should be
easier than the corresponding ideas for protecting 'user' disks, as
there should be no reason for a distribution disk to EVER change once
it has left the maker's hands.

- --
Paul Smee, Univ of Bristol Comp Centre, Bristol BS8 1TW, Tel [phone]
[e-mail]  :-)  (..!uunet!ukc!gdr.bath.ac.uk!exspes if you MUST)

------------------------------

Date:    16 Jan 90 15:21:44 +0000
From:    [e-mail]
Subject: Biological analogy source requested

I know there has been some discussion in this group of the extent
to which the analogy between computer viruses and their biological
cousins is tenable, though I have not followed it closely. However,
can anyone suggest any references on this topic? Alternatively, can
anyone suggest any good references on viruses in general. They
should preferably be in well-read journals, (so that they are likely
to be in our library, which has no books on the subject).

Thanks in anticipation.

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Wednesday, 17 Jan 1990    Volume 3 : Issue 13

Today's Topics:

Re: Shrink wrap...still safe?
XENO virus infection---help!!(Amiga)
Another WDEF infection (Mac)
WDEF at Arizona State University (Mac)
Vienna Virus (PC)
Re: Shrink Wrap...still safe?
Re: Biological references requested
Re: Morris stands trial (Internet)
Bulgarian viruses (PC)
Re: virus scanning

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

---------------------------------------------------------------------------

Date:    Tue, 16 Jan 90 15:04:31 -0500
From:    [e-mail] (David Gursky)
Subject: Re: Shrink wrap...still safe?

Several people in Virus-L V3 #12 suggested that were vendors to distribute
applications on write-locked media, the potential for vandalism by buying an
application, infecting it, and return it, would be reduced.

While that statement is broad enough to be true, I would suggest that the
suggestion is far to easy for a vandal (and not even a very determined one
at that) to get around, where 3.5" media is concerned.

With 3.5" disks, a small hole can be covered by a moving tab, to indicate
to the disk drive whether the disk is locked or not.  Open is locked, closed
is writable.  If vendors disseminate applications on write-locked 3.5" media,
all a vandal needs to do is cover the hole with a small piece of electrical
tape.

5.25" media is more difficult to pull this stunt with.  The presence of small
notch in the side of the flexible case means the disk is writable.  In order
for a vandal to infect an application shipped on 5.25" media, the vandal would
have to physically mar the case, which is a surer sign of tampering.

------------------------------

Date:    16 Jan 90 23:44:00 +0700
From:    "Okay, S J" <[e-mail]>
Subject: XENO virus infection---help!!(Amiga)

Arrrrggghhhh...After years of vigilance and checking everything I put in
the machines I use, I've finally been hit and hit bad.
My A2000 has contracted a bad case of XENO in just about all the directories
on my HD, so I am seriously considering a low-level format of my HD(fortunately
I have been wise enough to do continual backups and offloading).
So, questions for those Amiga users out there who have had Xeno, or from those
who know more technical details about it:
1. How did you deal with it???---I've about running KV on all of the infected
   files, but it appears that KV only disables, and doesn't remove the XENO
   virus. If this is true, how dangerous is an immobilized XENO, compared to
   a live one???---This is the main reason I am considering calling in an
   airstrike to blast my filesystem, since I'm assuming it could come back
   again in the same files if I ever catch a live copy again....
2. What exactly are the general symptoms. All I know is that I found it in my
   CRONTAB file ( which makes it a pretty stupid virus in my book...I basically
   have a disassembly of the little bugger tacked onto my CRONTAB entries),
   and some how it got into my Cron daemon
 and it spread from there....
3. Any other helpful hints/comments/ideas you might have to offer....

Comments:
I know who I got it from and he checked his system and it was crawling all over
there too, so the source has been isolated.
The way I found it was through my Startup-Sequence failing numerous times
because "echo", "date" and "read" had had their filetypes changed from
executables to scripts and had to be replaced.
I'd also been getting an inordinate amount of Guru meditation #'s, specifically
#000000003 (CPU trap).
It wouldn't have spread so fast I don't think if it hadn't gotten into Cron,
which I make heavy use of....
Its easy for this one to sneak by, because until now, we Amigoids haven't had
to worry about anything except for Boot-infectors. Hence, there were no
readily available file-infectors to detect it until recently.

If what I've seen is any indication, I'd say its a pretty stupid virus in
terms of propagation...like I said, I found it in my CronTab as well as a
few other script and non-executable files....

I figure if I don't hear back in a few days with contrary recommendations,
I'll just have my system "duck and cover" and drop a 20 megaton low-level
format bomb on the whole thing and be done with it.
- ----Steve
- -------------------
Stephen Okay
[e-mail]     Technical Aide, The MITRE Corporation

------------------------------

Date:    Tue, 16 Jan 90 22:05:00 -0500
From:    "Scott P Leslie" <[e-mail]>
Subject: Another WDEF infection (Mac)

Hello,
   The University of North Carolina at Chapel Hill has seen WDEF.
We now have Disinfectent 1.5 and GateKeeper Aid 1.??.
- -spl

------------------------------

Date:    Tue, 16 Jan 90 21:31:51 -0700
From:    Ben Goren <[e-mail]>
Subject: WDEF at Arizona State University (Mac)

For those of you trying to track WDEF (although I'm sure it's spread
everywhere by now), I just yesterday discovered WDEF A on an SE/30 in
the School of Music at Arizona State University.  I successfully removed
it with VirusDetective (after rembering that you can't do this from the
Finder) and immediately prepared a disk with clean copies of the latest
versions (as of 1/15/90) of GateKeeper, GateKeeper Aid, VirusDetective,
and Disinfectant (FTP'd from Info-Mac at Stanford), along with a
TeachText file describing each briefly and urging the usual "lock disks,
backup files, and don't pirate software" philosophy.

I am sure that the student use sites are infected, although I haven't
had a chance to check them personally--I haven't heard or seen anything
on campus about it, so I plan to call the various system administrators
to make sure they know about it.

My thanks and compliments to the three authors.  All four programs are
comprehensive, fill their function thoroghly, and are easy to use.

All opinions, etc., are my own.

........................................................................
     Ben Goren                                      T T T        /
         Trumpet Performance Major           )------+-+-+--====*0
         Arizona State University               ( --|-| |---)
         Bitnet:  AUBXG@ASUACAD                   --+-+-+--
........................................................................

------------------------------

Date:    17 Jan 90 06:16:56 +0000
From:    [e-mail] (Mark R. Slezak)
Subject: Vienna Virus (PC)

Just so others know about it; the Oregon State University Kerr Library Micro-
Computer Lab got hit with the Vienna virus. Once I figured out what it was it
was easy enough to get riof (using M-Vienna...)

Just though those who track the viruses might like to know...
+-----------------------------------------------------------------------------+
 Mark R. Slezak            {tektronix,hp-pcd}!orstcs!nyssa.CS.ORST.EDU!slezakm

------------------------------

Date:    16 Jan 90 15:42:54 +0000
From:    bnr-vpa!bnr-fos!bmers58![e-mail] (Mark Lord)
Subject: Re: Shrink Wrap...still safe?

[e-mail] (Earle Ake) writes:
>       If you have a virus on your system that reproduced your master
>diskette, that virus could infect the copy.  If the store that
>re-sells your software takes off the shrink-wrap, tests the program
>and re-shrink-wraps it, there is a chance of a virus infecting it
>there.  If someone buys a package, takes it home and discovers it will
>not work on his system and returns the software, the store
>re-shrink-wraps it and sells it for new.  Yet another way to infect a
>disk even though it was sold 'shrink-wrapped'.  Do we have to put all
>software in tamper-resistant packaging like Tylenol?  If a store tries
>a package out so they can be able to tell customers how good it is,
>can they sell that diskette as new software still?  Do we have to
>demand a no-returns policy on software?  Hey, the customer might have
>a shrink-wrap machine available to them and would be able to
>shrink-wrap and return as new.  Where do we draw the line?

Hmm.. the simple solution to most of these problems is to distribute
software on diskettes without write-enable slots (ie. built-in write
protection tabs).  There is simply NO way, short of modifying hardware,
for such diskettes to become virus infected on the customers premises.

I'm actually quite suprised that 99% of the software I purchase comes
*without* write protection tabs installed on the diskettes (5.25" floppies).
I really have to force myself to install that critical tab *before* inserting
the disk in *any* drive.  This guarantees that I don't infect the masters.

This whole deal with shrink-wrap and Tylenol-packaging for software is
really a big scam in a lot of ways (IMHO).

I mean, think about this.. the customer is expected to plop out (here in
Canada, at least) between $60 and $200 for the most trivial of store-bought
software, WITHOUT any guarantee of system compatibility (most people DO NOT
have IBM/COMPAQ/TANDY machines.. face it!).  In addition, if the program
does not work, or demonstrates bugs, TOUGH NUGGIES.. no source code to fix
and no replacements available.  Would you buy anything else *new* under such
outrageous conditions???  [other than software, of course]

Where is Ralph Nader when we need him?  Ooops.  Wrong country.

'cuse me while I take a long dandelion break...
- --
+----------------------------------------+----------------------------+
| Mark S. Lord                           | Hey, It's only MY opinion. |
| ..!utgpu!bnr-vpa!bnr-fos!mlord%bmers58 | Feel free to have your own.|
+----------------------------------------+----------------------------+

------------------------------

Date:    Wed, 17 Jan 90 10:29:36 +0700
From:    [e-mail]
Subject: Re: Biological references requested

A good reference about viruses in general as well as the analogy
between them and their biological coussins is:

J.C. Van Winkel, "The phenonemon computerviruses reviewed", 1989, NGI,
Amsterdam. ISBN: 90-70621-29-0.

Since their is a ISBN, I think you can order it in any bookstore. You
can also order direct by: NGI, 184 Van Diemenstraat, NL-1013 CP
Amsterdam, The Netherlands. It costs about $ 15,00.

------------------------------

Date:    17 Jan 90 13:36:11 +0000
From:    Irving Chidsey <[e-mail]>
Subject: Re: Morris stands trial (Internet)

[e-mail] (Damon Kelley; (RJE)) writes:

<Isn't a "jury of his peers" called for here?
<
<       She said that the trial would be more impartial if the jury is
<composed of non-tech persons.  Comments?

        There are two kinds of challanges, For Cause and Peremptory.
Each side gets an unlimited ( I think ) number of challanges for cause
and a moderate number of peremptory, just because, challenges.  The
defense gets more of the latter.  Both sides were probably afraid of
computer knowledgeble jurors because they know something about
computers.  Neither side wants experts on the jury, they are too hard
to sway and lawyers prefer pliable jurors who can be convinced by
rhetoric.

        I just finished a term as juror.  Got on one case, was
excluded from several others.  The cute blond prosecuting attorney
that turned me down was out of her mind :-).

                                                        Irv

I do not have signature authority.  I am not authorized to sign anything.
I am not authorized to commit the BRL, the DOA, the DOD, or the US Government
to anything, not even by implication.
                        Irving L. Chidsey  <[e-mail]>

------------------------------

Date:    17 Jan 90 15:05:00 +0700
From:    [e-mail]
Subject: Bulgarian viruses (PC)

                             Hello, everybody!

I am a computer virus expert from the Eastern block. My name is
Vesselin Vladimirov Bontchev and I live in Bulgaria. I have some
problems with the English language, so *please* excuse my mistakes.
Currently I am private for two months in Munich and for the first time
in my life I have access to an e-mail system. It is really wonderful!

The computer virus situation in our country is completely different.
We do not have too many kinds of viruses -- about 10-12 for IBM
PC/XT/AT and compatibles only -- but they are *very* widely spread.
One can find them just everywhere -- not only in high schools and
computer clubs.  The main reason is that literally no one takes
particularly care to prevent the infection and to exterminate the
viruses.  Another main reason is that the level of software piracy in
our country is very high -- there is no copyright law there.  I wrote
some antivirus programs which I am distributing freely and they are
widely used -- but of course, one cannot defeat alone the virus
threat.

If someone is interested, I am able to supply detailed information
about the viruses "made in Bulgaria":
        - Dark Avenger
        - VACSINA
        - Yankee Doodle
(In fact, the last two are different versions of a single virus -- and
I know very well the person who created them.)

As far as I know, these viruses are already spread in the Western
countries. There are also other "Bulgarian" viruses:
        - V651
        - V512
        - V2000

I can also supply information about them. If they have already spread
outside Bulgaria, please let me know.

The other viruses which are spread in our country are:
        - VHP-648 (Vienna)
        - Bouncing Ball (Italian, Turin)
        - V1813 (Israeli, Jerusalem, Friday 13th)
        - V1701/V1704 (Cascade, Autumn, Falling letters)
but they are too well known, so I do not think that someone will need
information about them.

                        Sincerely,
                                        Vesselin

------------------------------

Date:    17 Jan 90 15:07:00 +0700
From:    [e-mail]
Subject: Re: virus scanning

> I am told that in the November '89 issue of the American Mathematical
> Monthly, to the effect that no completely safe computer virus test is
> possible.  The proof is suppose to be short, and along the lines of
> the various proofs of the Halting problem.

Yes, the problem whether a program is a virus or not, is in general
undecidable. The (informal) proof follows:

Let's define a virus as a program which can infect other programs. (For a
more complete definition, see [1].) Let A(P) be an algorithm which applied
to the program P returns a boolean value (true when P is a virus and false
if it isn't). Now we can construct the program P1 in the following way:

        program P1;
        begin
                if A(P1)
                then (* do nothing *)
                else infect_other_programs;
        end.

In other words, if A reports that P1 is a virus, then P1 does not infect
programs, i.e. is not a virus. Otherwise (if A reports that P1 is not a
virus), P1 infects programs, i.e. it is a virus.

Therefore, A cannot decide whether P1 is a virus or not.
                                        Q.E.D.

                        Vesselin

[1] Cohen F., "Computer Viruses. Theory and Experiments", COMPUTER
    SECURITY: A Global Challenge, J.H. Finch and E.G. Dougall (eds.),
    Elsevier Science Publishers B.V. (North-Holland), 1984.

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Thursday, 18 Jan 1990    Volume 3 : Issue 14

Today's Topics:

New York Times on the Morris Trial
Shrink-Wrap and Write-Protection
Re: Shrink-Wrapped Software
Re: Some more thoughts on shrink-wrapped software...
Internet Worm Creator goes to trial
Re: Shrink wrap...still safe?
Re: Internet worm writer stands trial (Internet)
Pakistan C-Brain Virus
Re: Internet worm writer stands trial (Internet)
*** POSSIBLE VIRUS WARNING *** (PC)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

---------------------------------------------------------------------------

Date:    Wed, 17 Jan 90 12:45:25 -0700
From:    Chris McDonald <[e-mail]>
Subject: New York Times on the Morris Trial

William Murray recently asked where John Markoff was when we needed
coverage of the Morris trial.  Thirty minutes later I read a lengthy
article in the Arizona Republic attributed to the New York Times.  I
am including in quotations only those items which I have not seen
previously on Virus-L or Risks Forum.  These are direct quotes which I
have not independently verified for their accuracy.

"Indeed, Morris' lawyer said that to show his client as a proponent of
safeguarding computer security, he will introduce as evidence a videotape
that shows the defendant giving a lecture at the National Security Agency
in 1987 on how to gain access to computers illicitly."

"But in its case against Morris, the prosecution also plans to use the
videotape."

"The videotape of Morris's lecture at the National Security Agency came
to light recently when Morris' lawyer filed legal papers to introduce
classified material at the trial related to the film."

"The lecture, which was not classified, was presented at the security
agency at the request of the defendant's father, Robert Morris, the
chief scientist of the agency and an internationally know computer-
security (sic) expert."

"The younger Morris' lawyer, Thomas A. Guidoboni, said the circumstances
surrounding the lecture and a similar talk that Morris gave at the Naval
Research Laboratory the same year are significant in that they create a
view of Morris as someone who has acted responsibly on computer-security
issues."

"But Guidoboni also said that seen in isolation, without an explanation of
the circumstances, the tape could harm Morris' case."

"The elder Morris has told lawyers that describing the subject of the
lecture and the makeup of the audience, as the defense wants to do,
would require the disclosure of classified information, which he said he
would not do."

"The issue of whether classified data will be used at the trial has not
been resolved."

Chris Mc Donald
White Sands Missile Range
- -------

------------------------------

Date:    Wed, 17 Jan 90 15:35:00 -0500
From:    [e-mail]
Subject: Shrink-Wrap and Write-Protection

>With 3.5" disks, a small hole can be covered by a moving tab, to
>indicate to the disk drive whether the disk is locked or not.  Open is
>locked, closed is writable.  If vendors disseminate applications on
>write-locked 3.5" media, all a vandal needs to do is cover the hole
>with a small piece of electrical tape.

Without intending to minimize the threat of vandals, the damage that
they do is vanishingly small when compared to errors by the
well-intentioned.  The danger to which this mechanism was addressed
was the accidental and unwitting contamination of a distribution
diskette.  It was not intended to protect against the less likely
vandalism.

William Hugh Murray, Fellow, Information System Security, Ernst & Young
2000 National City Center Cleveland, Ohio 44114
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840

------------------------------

Date:    16 Jan 90 19:11:20 +0000
From:    ensys.ensys.com!silvlis.com![e-mail] (Michael S. Maiten)
Subject: Re: Shrink-Wrapped Software


[e-mail] writes:

>   Vendors can help by using labeled shrink-wrap.  To the extent that
>   users come to expect such labeling, the re-wrap strategy becomes less
>   effective and efficient for the retailer.

Much of the discussion of the "shrink wrap" issue is focused on the
inability of the purchaser to determine if the disk has ever been
used and rewrapped.

In my opinion, a solution to this problem is for the software
publishers to use disks that are permanently write-protected.  (ie; no
notch on 5.25" disks and a hole without slider on 3.5" disks).  This
will not stop a determined terrorist from infecting disks, but it will
stop the casual accidental infection of purchased software.

>   Users can protect themselves
>   and discourage this risky practice by refusing to deal with retailers
>   that offer them the right to return.

Stores that offer return policies are exactly the ones with whom I do
deal, since it is almost impossible to see if the software will meet
my needs by reading the box or trying out the store demonstration
copy.  What they should do is to be more careful when accepting the
returned items (check for missing materials, and check for infection
of the disks) before returning the person's money.

- ------------------------------------------------------------------------------
Michael S. Maiten                 Internet:    [e-mail]
Energetic Systems                       or:    [e-mail]
Telephone: [phone]        UUCP:        {sun!silvlis,bridge2}!ensys!msm

------------------------------

Date:    17 Jan 90 22:30:12 +0000
From:    [e-mail] (James P. Willey)
Subject: Re: Some more thoughts on shrink-wrapped software...

[e-mail] (David Gursky) writes:
>What is really most amazing about the problem of a potential vandal infecting
>a commercial application, and returning it to an unsuspecting vendor is the
>ease with which the vendor can detect the problem.  Consider the following
>scenario:

      I work at a small software store, and I noticed several problems with
this scenario.

>1 -- An application is returned to a vendor.

Yes, unfortunately this does happen frequently.

>2 -- Proof of purchase is produced, vendor agrees to accept product, but does
>     not yet refund purchase price.
>
>3 -- A second copy of the shrink-wrapped application is removed from the
>     shelf.

Assuming, of course, that the store has another copy on the shelf.
This would also waste a lot of time reshrink wrapping software.

>4 -- The disk(s) from the returned copy are then byte-by-byte compared against
>     the disk(s) in the shelf copy from step 3.

Assuming, of course, that the store has the computer that the software
is for.  At the store I work at, we carry IBM, Mac, and Apple, but we
only have an IBM computer.  Also, the store may only have 5.25 drives
and the software in question is on 3.5 disks.  The computers are also
used for demo software in case someone wants to see it run before they
but it.  Checking every disk

I agree that something should be done, but this isn't the answer for
everyone.

-
 -------------------------------------------------------------------------------
James P. Willey                           [e-mail]
Disclaimer:  I'm now employed, but I'm responsible for my employers opinions,
                not vice versa.

------------------------------

Date:    Wed, 17 Jan 90 20:37:33 +0300
From:    Geraldo Xexeo <[e-mail]>
Subject: Internet Worm Creator goes to trial

I suppose that all the computer community have already judged the
worm creator in discussions around the world, so it is fair
to make a jury of "non-computer" people.

My point is, this trial don't eliminates the necessity of a
ethical judgement. Maybe what he did is not a crime, but is clearly
a violation of ethical aspects of computer use.

I suggest that a ethical code, similar to the ethical code in
medicine should be developed. I suppose that ACM has one, but is not
the same. ACM  didn't control the exercise of the computer activities.

                          Geraldo Xexeo
                          [e-mail]

------------------------------

Date:    Thu, 18 Jan 90 01:31:44 +0000
From:    [e-mail] ()
Subject: Re: Shrink wrap...still safe?


Several writers have suggested that vendors distribute software
on 5.25" diskettes without write-enable notches since evidence of
tampering with such diskettes is fairly obvious.

A sheet-metal notching tool cuts a very clean write-enable notch
which can fool many users.  Thus, I would suggest that vendors
distributing software on diskettes without write-enable notches
also add a warning ON THE DISKETTE LABEL stating that the diskette
was manufactured without a write-enable notch and that the buyer
should reject any diskette with a write enable notch cut in it.

Al Stangenberger                    Dept. of Forestry & Resource Mgt.
[e-mail]          145 Mulford Hall - Univ. of Calif.
uucp:  ucbvax!ucbviolet!forags      Berkeley, CA  94720
BITNET: FORAGS AT UCBVIOLE          [phone]

------------------------------

Date:    Wed, 17 Jan 90 12:56:16 +0000
From:    biar![e-mail] (Robert J Woodhead)
Subject: Re: Internet worm writer stands trial (Internet)

[e-mail] (Damon Kelley; (RJE)) writes:

>       When I read the article that I got the above information from,
>I was a bit shocked that the jurors were deliberately picked by the
>U.S. Justice Department lawyers because didn't know *anything* about
>computers.  Would the jurors understand enough of the computer talk
>thrown between defense and prosecutor to reach a truly informed
>verdict?

I'm not surprised that the jurors are technically incompetant; people
who have any competence in the field at issue are regularily excluded
from juries, usually by the defense though.  In drug trials, the defense
as a matter of course tries to go for as stupid a jury as possible as
they 1) are less likely to understand why the defendant is guilty and
2) are less likely to acquit.

Look at it this way; if you or I or any of the readers of this newsgroup
were on the jury, our technical knowledge would give us an "advantage"
over the other jurors which we could use to sway them to support our
position.

Juries are not totally to blame for insane verdicts and awards; part of
the blame must be put on the system that tends to impanel incompetant
juries.  In my circle of admittedly bright and educated friends, not
a single one has, to my knowledge, ever been accepted for jury duty.

- --
Robert J Woodhead, Biar Games, Inc.   !uunet!biar!trebor | [e-mail]
Announcing TEMPORAL EXPRESS.  For only $999,999.95 (per page), your message
will be carefully stored, then sent back in time as soon as technologically
possible.  TEMEX - when it absolutely, postively has to be there yesterday!

------------------------------

Date:    17 Jan 90 21:33:11 +0000
From:    [e-mail] ( Michael A. Gallo)
Subject: Pakistan C-Brain Virus

Help....

We need assistance in eliminating the Pakistan C-Brain virus from our
IBM PCs and compatibles.  The virus has infected virtually all of our
PCs located in our microcomputer center, which is an open lab on
campus.

Any information that anyone can provide will be most beneficial.
Please e-mail any helpful responses to [e-mail].  Thanks.

Mike Gallo
Florida Institute of Technology
Melbourne, FL 32901
[phone] x7551
Internet: [e-mail]
UUCP:  ...!uunet!pd1!winnie!zach!gallo

------------------------------

Date:    18 Jan 90 14:29:37 +0000
From:    [e-mail] (Cris Simpson)
Subject: Re: Internet worm writer stands trial (Internet)


[e-mail] (Damon Kelley; (RJE)) writes:
>  [...]
>       When I read the article that I got the above information from,
>I was a bit shocked that the jurors were deliberately picked by the
>U.S. Justice Department lawyers because didn't know *anything* about
>computers.  Would the jurors understand enough of the computer talk
>thrown between defense and prosecutor to reach a truly informed
>verdict?
>
>       My mother and I discussed the issue.  I said that the trial
>would be unbalanced and handled badly because every little techie term
>would have to be explained over and over again to the jury, slowing
>down the trial process.  Isn't a "jury of his peers" called for here?
>  [...]
>Source: _The_Baltimore_Evening_Sun_, January 15, 1990. Section D, top
>of page 2: "'Illiterates' Judging Computer Genius."   [..]

        One of the most frightening experiences of my life was being
called to jury duty.  I got to see what a 'jury of my peers' would
consist of.  It gives one a lot of incentive not to get caught. (:-)

IANAL, but I see a problem in the future with technology-related
litigation.  What good is the right to have your case tried before
a jury of idiots?  For example, consider Intel v. NEC or Apple v.
MS & HP.  It's hard enough explaining the concepts involved to a
reasonably intelligent judge, but a jury picked because they didn't
know anything?

I suppose that if a jury of people from Washington, DC can be found
who never heard of Ollie North, I suppose there's a jury for all of
us...  (:-)

cris

*IANAL: I Am Not A Lawyer.  (But my wife is.)

------------------------------

Date:    17 Jan 90 19:54:25 +0000
From:    [e-mail] (Glenn Pitcher)
Subject: *** POSSIBLE VIRUS WARNING *** (PC)

[Ed. Forwarded from comp.sys.ibm.pc]

Apparently, we have run across our first real virus.  As of now, it's not
fully know what this can do or even what program is doing it but here's
a description of a file that keeps on appearing on our systems...

The file name is '800' and appears in the root directory.  File size is
368K and contained in the file are text strings that contain copyright messages
for Compac Computer Corp. (no, our systems are from another manufacturer).
Twords the bottom of the file, it appears to have a questionaire pertaining to
animal laboratory research.

If anyone else knows *anything* about this, please post it...

Thanks,
- --
Glenn Pitcher                              UUCP: {crash,ucsd}!edpmgt!gpitcher
Programmer/Analyst &                       ARPA: Too many $$$
Unix Guru in training                    BITNET: A net for runaway programs
EDP Management, Inc.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
- -

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Friday, 19 Jan 1990    Volume 3 : Issue 15

Today's Topics:

Academic Press makes good! (PC)
Hard Drive Overlord (PC)
Re: Spool... Bug or Virus, what is more harmful
Re: Shrink-Wrapped Software
Re: Internet worm writer stands trial (Internet)
Re: Internet worm writer stands trial (Internet)
Ethical Judgement of the Internet Worm
fractal disk infection (PC)
WDEF at University of Oregon (Mac)
New anti-virals uploaded to SIMTEL20 (PC)
McAfee Included in top 100
Re: virus scanning
Re: Some more thoughts on shrink-wrapped software...
Shrink-wrapped SW

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

---------------------------------------------------------------------------

Date:    Thu, 18 Jan 90 13:33:40 -0500
From:    [e-mail]
Subject: Academic Press makes good! (PC)

Well, Academic Press finally came through!  You will recall that
the Barnsley DESKTOP FRACTAL DESIGN SYSTEM, sold through Academic
Press, was infected with a virus named "1813".  At the time I reported
this to Academic Press's Customer Service department, they knew about
the problem.  Yesterday I received a letter from them dated January
12 (about 2 days after I reported the virus) noting that some copies
of the program are "suspected of carrying a computer virus."  The
letter directs purchasers to call the Customer Service Department
to order a clean copy and get directions for how to clean up your
system.

I'm not sure why it took them so long, but at least AP is taking
responsibility.  I imagine their senior executives are holding
their aching heads and wondering why they decided to enter the
software publishing business.  Books never require product recalls.
   +-----------------------------------+---------------------------+
   |  ___                              |     Barbara Weitbrecht    |
   | (__  \      /           \         |    Computer Specialist    |
   | ___)EAL\/\/ YF       >-===-:}     |  Smithsonian Institution  |
   |                         /         |      IRMSS100 @ SIVM      |
   +-----------------------------------+---------------------------+
   |  The Sealwyf is a shape-shifter -- a woman in a seal's skin.  |
   +---------------------------------------------------------------+

------------------------------

Date:    Thu, 18 Jan 90 13:04:21 -0500
From:    Jim Kenyon <[e-mail]>
Subject: Hard Drive Overlord (PC)

I am trying to get information on a programme called Hard Drive
Overlord which is published by A.B. Data Sales, Inc. of Saskatoon,
Saskatchewan, Canada.

It comes with five modules and seems to be similar to GateKeeper (Mac)
in function.  With all the discussion on the list about software, it's
hard to imagine why this one hasn't been mentioned before.

Please reply directly to me and I'll post a summary back.

Jim Kenyon                      NetNorth: [e-mail]
Director, Veterinary Services   CONNECT:  Macvet
The Toronto Hospital
Toronto, Ontario, Canada        [phone]

------------------------------

Date:    Thu, 18 Jan 90 08:40:03 -0500
From:    Geraldo Xexeo <[e-mail]>
Subject: Re: Spool... Bug or Virus, what is more harmful

  Some Digests ago there was a message saying that our errors are more
dangerous than virus. Could both of them be viewed in the same
perspective? Could "vaccines" be developed for both?

Second Point:
  Lately I receiving lots of RETURNED NETWORK from LISTSERVERS. I think
that it could cause, in extreme case, a traffic so large in the net
that it would collapse.

  Question: In this case, the LISTSERV will be considered a Virus (expecting
to get active)? Or the users that don't disconnect itself from servers are
guilty of bad use (non-ethical) of a computer program?

  Although it is not the place, I suggest that LISTSERVERs receive an
ANTI-MESSAGE protection to solve this specific problem, but I'm worried
with the generalization of this question.

                        Geraldo Xexeo
                        [e-mail]

[Ed. Believe it or not, LISTSERVs actually attempt to parse incoming
mail to determine whether it is a bounced error message (in which case
the mail gets forwarded to me...) or a legitimate posting.
Unfortunately, postmasters and sites don't use any standard format
error message, and the LISTSERV occasionally is "tricked" into
believing that an error is actually a message for the list.  Instant
loop, just add water.  Those of you on VALERT-L may be relieved to
know that I *think* that the problem is fixed.  I know, I know -
famous last words...  :-)]

------------------------------

Date:    18 Jan 90 20:58:44 +0000
From:    Bernie Cosell <[e-mail]>
Subject: Re: Shrink-Wrapped Software

ensys.ensys.com!silvlis.com![e-mail] (Michael S. Maiten) writes:

}[e-mail] writes:

}>   Users can protect themselves
}>   and discourage this risky practice by refusing to deal with retailers
}>   that offer them the right to return.

}Stores that offer return policies are exactly the ones with whom I do
}deal, since it is almost impossible to see if the software will meet
}my needs by reading the box or trying out the store demonstration
}copy.  What they should do is to be more careful when accepting the
}returned items (check for missing materials, and check for infection
}of the disks) before returning the person's money.

Actually, isn't this almost totally trivial for the store --- all they need
to is, before they re-shrink-wrap, do a sector-by-sector, byte-by-byte
comparsion of the *entire* disk(s) that were returned against a master set
the store keeps.  It doesn't seem hard, and surely cannot take long, and far
as I can tell totally elminates the problems.

  /Bernie\

------------------------------

Date:    Thu, 18 Jan 90 17:57:47 +0000
From:    "Ralph Treitz" <sapwdf![e-mail]>
Subject: Re: Internet worm writer stands trial (Internet)

It was interesting to hear about the sequel of the Internet-worm-story.
For our newspapers didn't mention anything about the trial, I'd like to
hear in this newsgroup, what's going on, and what will happen to Mr. Morris.
Thanks.

 +----------------------------------+----------------------------------------+
 !    Ralph Treitz                  !    Phone:  +49 6227 - 34 - 1641        !
 !    S.A.P. AG                     !    Fax:    +49 6227 - 34 - 1282        !
 !    SAA-C                         !    Telex:  466 004 sap d               !
 !    Max-Planck-Str. 8             !                                        !
 !    D-6909 Walldorf/Baden         !    E-Mail: [e-mail]              !
 !    West-Germany ( F.R.G. )       !            ...uunet!unido!sapwdf!rt    !
 +----------------------------------+----------------------------------------+

------------------------------

Date:    18 Jan 90 22:34:50 +0000
From:    [e-mail] (Robert Rubinoff)
Subject: Re: Internet worm writer stands trial (Internet)

biar![e-mail] (Robert J Woodhead) writes:
> [...] In my circle of admittedly bright and educated friends, not
>a single one has, to my knowledge, ever been accepted for jury duty.

Well, I've never met RJW, so I don't qualify as a friend of his, but
I'm a PhD student in Computer Science at Penn, so I'm definitely
educated and presumably bright as well (at least I like to thing so).
I was just selected to serve on a jury even though I mentioned during
the selection process that I was a PhD student.  So I guess it's not
impossible.

    Robert

------------------------------

Date:    Thu, 18 Jan 90 15:07:00 -0500
From:    [e-mail]
Subject: Ethical Judgement of the Internet Worm

>From VIRUS-L:

>My point is, this trial don't eliminates the necessity of a
>ethical judgement. Maybe what he did is not a crime, but is clearly
>a violation of ethical aspects of computer use.

I suspect the conclusion of the authorities at Cornell that young Morris
acted with "reckless disregard" for the consequences is the closest that
we will ever get to an ethical judgement about his actions.

>I suggest that a ethical code, similar to the ethical code in
>medicine should be developed. I suppose that ACM has one, but is not
>the same. ACM  didn't control the exercise of the computer activities.

Of course the ACM does have such a code, and it is likely that young
Morris has or would subscribe to it.  However, it did not deter him.
Since his lawyer plans for him to testify, we will likely get to hear
his rationale for his behavior.  However, I doubt that he seriously
considered the ethics of his actions until confronted with the
consequences.

Had he done so, I am not sure that it would have altered his behavior.
Like many of his defenders in the net, I suspect that he would have seen
as ethical, or as not an ethical issue.  There does not seem to be a
concensus among his contemporaries that that kind of behavior is
reprehensible.  Neither does there appear to be a concensus among them
that they have an interest in an orderly playground.

Note that though Morris aspires to be a professional in the field, and
is, therefore, subject to professional sanctions, most of his
contemporaries who use computers have no such aspirations and are not
subject to such sanctions.

It seems equally clear that this profession does not have sufficient
integrity to inoke such sanctions.  Though Cornell concluded that he
did it (and he does not deny it), they have said that he is eligible
to re-apply for admission to continue his studies.  Other
"responsible" members of the profession have been willing to employ
him.  Thus his contemporaries could conclude that, while such actions
might be in technical violation of the ACM's code, they are not in
violation of community standards.

If the profession and society are to be protected from such impolite,
disorderly, and destructive behavior, then we must reach a collective
conviction we are prepared to consistently support in both
voice and action.  In the absence of such a concensus, we can expect
more of the same.

William Hugh Murray, Fellow, Information System Security, Ernst & Young
2000 National City Center Cleveland, Ohio 44114
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840

------------------------------

Date:    Thu, 18 Jan 90 19:49:49 -0000
From:    [e-mail]
Subject: fractal disk infection (PC)

TO ANYBODY FIGHTING THE JERUSALEM/1813 VIRUS ON THE "DESKTOP FRACTAL
DISK"

There are two articles which explain the action of the virus and give
details of anti-viral programs to eradicate it:

Joe Hirst Getting inside PC viruses. Tech PC User may 1989 v1 n9 p22(5)

Powis, Kevin Programs to fight viruses. Tech PC User May 1989 v1 n9 p31(3)

The program to fight Jerusalem/1813 is called 1813BR, it's PD and you
can get it from the CoTRA conference on CIX

Rgds,

Iain Noble

------------------------------

Date:    Thu, 18 Jan 90 13:44:00 -0800
From:    "Hervey Allen" <[e-mail]>
Subject: WDEF at University of Oregon (Mac)

Since people seem to be reporting occurrences of the WDEF virus, hopefully
to track its spread, I will throw in my two cents worth.

The WDEF virus was reported in the student computer lounge around January
8th.  The virus was removed using Disinfectant 1.5.  The computer lounge
has a voluntary virus check station.  The WDEF virus has been detected and
removed a number of times since the 8th.

I am writing from the University of Oregon Academic Computing Center.  We
have not seen the WDEF virus yet.  We scan numerous disks that are brought
into our public printing and public domain (both for Macintosh) stations.
We have exclusively seen Nvir A and B.  I informally track virus reports
from around the city (Eugene, Oregon) and have only received reports of
Nvir A and B.

On the PC side I have dealt with the Jerusalem virus once, and the Ping-
Pong virus once.  The Jerusalem virus was spread from a BBS in Portland,
Oregon.  No other PC viruses have been reported to our center.

Obviously, we have been lucky, so far.  One of my duties is virus removal
and prevention for PC and Macintosh at our center.  I receive numerous
calls for information and help from the campus community and the community
in general.

Hervey Allen              | Unversity of Oregon
Student Programmer        | Academic Computing
                          | [e-mail]  (internet)
                          | [e-mail]       (Bitnet)

------------------------------

Date:    Thu, 18 Jan 90 21:06:00 -0700
From:    Keith Petersen <[e-mail]>
Subject: New anti-virals uploaded to SIMTEL20 (PC)

I have uploaded the following files to SIMTEL20:

pd1:<msdos.trojan-pro>
CLEANP55.ARC    Universal Virus disinfector, heals/removes
SCANV55.ARC     VirusScan, scans disk files for 60 viruses

These programs where downloaded from the Homebase BBS.

- - - --Keith Petersen
Maintainer of SIMTEL20's CP/M, MSDOS, & MISC archives [IP address 26.2.0.74]
Internet: [e-mail], [e-mail]  BITNET: w8sdz@NDSUVM1
Uucp: {ames,decwrl,harvard,rutgers,ucbvax,uunet}!wsmr-simtel20.army.mil!w8sdz

------------------------------

Date:    Thu, 18 Jan 90 16:05:33 -0800
From:    [e-mail]
Subject: McAfee Included in top 100

     The Microtimes third annual selection of the 100 most influential
leaders in the computer industry (published in the January 22 edition)
includes John McAfee for his work in the computer virus field.  To see
a virus researcher included with such luminaries as Steven Jobs, Bill
Gates, Mitch Kapor, Peter Norton, John Akers (Chairman of the Board of
IBM), Phillipe Kahn etc. implies that the establishment has finally
taken the virus issue seriously.  It's even more interesting when you
consider that Steve Wozniak, Brian Carlson, the Chairmen of ICL,
Intel, Olivetti, and the presidents of dozens of major computer
manufacturers were turned down for inclusion.
     I say hats off to a hard working representative of the antivirus
league and congratulations -- in spite of John's self deprecating
attitude (He claims that they confused him with someone else and that
his inclusion and description of his deeds can be attributed to an
editorial oversight).

Alan Roberts

[Ed. Congratulations, John!]

------------------------------

Date:    Thu, 18 Jan 90 09:46:10 -0700
From:    mummy![e-mail] (Dave Myers)
Subject: Re: virus scanning

>> I am told that in the November '89 issue of the American Mathematical
>> Monthly, to the effect that no completely safe computer virus test is
>> possible.  The proof is suppose to be short, and along the lines of
>> the various proofs of the Halting problem.
>
>Yes, the problem whether a program is a virus or not, is in general
>undecidable. The (informal) proof follows:
>
>Let's define a virus as a program which can infect other programs. (For a
>more complete definition, see [1].) Let A(P) be an algorithm which applied
>to the program P returns a boolean value (true when P is a virus and false
>if it isn't). Now we can construct the program P1 in the following way:
>
>        program P1;
>        begin
>                if A(P1)
>                then (* do nothing *)
>                else infect_other_programs;
>        end.
>
>In other words, if A reports that P1 is a virus, then P1 does not infect
>programs, i.e. is not a virus. Otherwise (if A reports that P1 is not a
>virus), P1 infects programs, i.e. it is a virus.
>
>Therefore, A cannot decide whether P1 is a virus or not.
>                                        Q.E.D.
>
>                        Vesselin

I may be missing something, but it seems the above program makes the
assumption that A cannot detect some virus.  If A can detect all
virisus then P1 will in fact be unable to infect another program and
is thus not a virus.

dave

------------------------------

Date:    17 Jan 90 19:03:01 +0000
From:    [e-mail] (Woodrow Baker)
Subject: Re: Some more thoughts on shrink-wrapped software...

[e-mail] (David Gursky) writes:
> What is really most amazing about the problem of a potential vandal infecting
> a commercial application, and returning it to an unsuspecting vendor is the
> ease with which the vendor can detect the problem.

Why not just run a good virus checker on returned software  before rewrapping?

Cheers
Woody

------------------------------

Date:    Thu, 18 Jan 90 10:16:57 +0100
From:    iaoobel![e-mail] (Christof Ullwer)
Subject: Shrink-wrapped SW

In V3#12 Brian Piersel <[e-mail]> writes:
>Another way vendors can help is to sell software on write-protected
>diskettes.

And [e-mail] (Leonard P Levine) writes:
>Many vendors are now selling software on un-notched disks.  My most
>recent copy of wordstar, my copy of spinrite and even one shareware
>product have come to me on disks that cannot be written to except with
>modified computer hardware.

IMO, if someone evilminded really intends to infect a disk will
succeed even on write protected disks. On the other hand, verifying a
returned disk with a master copy as [e-mail] (David
Gursky) suggests is time intensive and annoys the customers. Vendors
should put a new media i.e. a copy from a clean master diskette into
the box and then shrink-wrap it.

Christof
([e-mail])

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Friday, 19 Jan 1990    Volume 3 : Issue 16

Today's Topics:

Re: Internet Worm Creator stands trial
Re: Internet worm writer stands trial
BitNet *can* FTP now.....
Internet Worm Trial
New files (PC)
Re: Ethical Judgement of the Internet Worm

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

---------------------------------------------------------------------------

Date:    19 Jan 90 01:14:53 +0000
From:    munnari!mullian.ee.mu.oz.au![e-mail] (Inspector Gadget)
Subject: Re: Internet Worm Creator stands trial

[e-mail] (Geraldo Xexeo) writes:
>I suppose that all the computer community have already judged the
>worm creator in discussions around the world, so it is fair
>to make a jury of "non-computer" people.
>
>My point is, this trial don't eliminates the necessity of a
>ethical judgement. Maybe what he did is not a crime, but is clearly
>a violation of ethical aspects of computer use.

        Virtually any person accused of crimes that have been given
wide publicity will find a jury with its opinions formed _prior_ to
the court case. "Non-computer people" would have also been exposed to
the media hype surrounding the Internet Worm, but exposed to rather
less well informed comment than "computer people".  It is _not_ "fair"
to have a jury of computer illiterates on the simple grounds that they
have less chance of seeing through the rubbish thrown up by either
side.

        The whole issue of what consitutes an 'ethical' use of
computers is thorny enough as it is. Just what sort of understanding
of computer ethics do you expect a jury of "non-computer people" to
have ? End result is that a whole swag of 'computer experts' have to
be called in to give evidence about what is and isn't ethical
behavious. In any case I've never known courts to be concerned about
ethics, per se. The letter of the law (and its multiple possible
intended meanings) are the deciding factors. Ultimately it comes down
to the ability of the jurors to map laws made from a non-computer
environment onto a computer environment and decide which ones the
defendant has broken. I can't see any benefit in having computer
illiterates doing this job.

Grenville Armitage.

"Only dead fish go with the flow" - someone else.
To be arrogant you need to have opinions. Therefore these
opinions are all mine, thank you very much.

------------------------------

Date:    Fri, 19 Jan 90 12:32:00 +0000
From:    Todd Hooper <munnari!mail.cut.oz.au![e-mail]>
Subject: Re: Internet worm writer stands trial

[e-mail] (Damon Kelley; (RJE)) writes:
> Mr. Morris is a student who was suspended from Cornell University
> because of his actions.

I would remind you that he _allegedly_ unleashed the Internet Worm.
Innocent before proven otherwise and all that stuff, you know...

>       When I read the article that I got the above information from,
> I was a bit shocked that the jurors were deliberately picked by the
> U.S. Justice Department lawyers because didn't know *anything* about
> computers.  Would the jurors understand enough of the computer talk
> thrown between defense and prosecutor to reach a truly informed
> verdict?

In Australia at least, this is standard procedure in trials. For
example, let's say someone had been charged with stealing a sportscar
from some executive type. The defence lawyers will try to 'stack' the
jury by rejecting all jurors who may be executives or own sportscars
or the like, in case they are biased towards the prosecutions case.

> [bits deleted]
>
>       Those lawyers better straighten up.  Not all computer
> enthusiasts practice regularly what Mr. Morris did, nor do they openly
> encourage the wanton destruction of computer systems "for a kick."

Again, I don't think the Internet Worm was intended to be malicious.
From the reports I've read, the author had intended it to be a sort of
'advanced networking experiment' ;-). Granted, that isn't a valid
excuse, but you can hardly paint a picture of Morris as a wanton
vandal, destroying computers for a kick.

- --
Todd Hooper                                                Computing Centre
                                            Curtin University of Technology
PSImail: psi%050529452300070::CHOOPER                     Western Australia
ACSnet : [e-mail]
Bitnet : [e-mail]
UUCP   : {enea,mcvax,uunet,ubc-cs,ukc}!munnari!acad.curtin.edu.au!CHOOPER
Phone  : [phone] (24 hour messaging system) Fax [phone]

------------------------------

Date:    Wed, 17 Jan 90 22:05:45 -0600
From:    James Ford <[e-mail]>
Subject: BitNet *can* FTP now.....

SCANV55.ZIP and VSTOP54.ZIP are available via anonymous FTP from
MIBSRV.MIB.ENG.UA.EDU (130.160.20.80) in the directory
pub/ibm-antivirus.  For those people who can *not* FTP, guess what!
You can!  And all for $1.99!

Seriously, Bitnet nodes can request files from BITFTP@PUCC.  The
following text explains how to go about this process.  *WARNING* It
might be *real* slow if many requests are in queue (sp?).

James Ford - [e-mail], [e-mail]

- -------------- Mailfile sent with HELP as the message text ----------------

[Ed. Due to its length, I've removed the help listing.  However, to
get your very own copy, send mail (or interactive message) to
[e-mail].  In the message, include the text:

HELP

...and you'll get information mailed to you on how to use the BITFTP
facility.]

------------------------------

Date:    Fri, 19 Jan 90 08:11:53 -0500
From:    Bridget Rutty <[e-mail]>
Subject: Internet Worm Trial

I believe most of the testimony is completed.  Morris testified
yesterday and said that he had written the worm so that it would
spread through the network but that he had not intended it to hurt any
of the computers.  He attempted to get help from a friend who
testified that he had suggested writing a second program to try to
trap and destroy the first one.  Morris decided not to because he
thought that would make matters worse.

To my mind he should be convicted.  There was no purpose to the
program other than spreading through the network and consuming
resources.  This is clearly unethical, and in the case of federal
defense networks, criminal.  How badly the computers were affected is
only a matter of degree which probably should be taken into
consideration for sentencing if he is convicted.

What is interesting to me is that he spoke to two different groups on
computer security, one of which was (I think) a government agency.
This speech was videotaped and apparently is being used as evidence by
both the prosecution and the defense!  The defense lawyers want to
introduce as evidence who attended the conference (or whatever) but
the list of attendees is classified information.  The video is not.

This is all I have gleaned from a partial reading of last night's
paper.  I don't generally read the local papers as I don't have a very
high opinion of them.  I can't afford to spend vacation time attending
the trial (much to my regret) so I can't give a blow by blow
description.  Sigh.

------------------------------

Date:    Fri, 19 Jan 90 10:28:53 -0600
From:    James Ford <[e-mail]>
Subject: New files (PC)

The following files have been added to MIBSRV.MIB.ENG.UA.EDU
(130.160.20.80):

File             Description                            received from
- -----------      -----------                            -------------
SCANV56.ZIP   -  Scan V56                               (Homebase BBS)
SCANRS56.ZIP  -  Scan V56 (tsr)                         (Homebase BBS)
SHEZ51.ZIP    -  ZIP, ARC, LHZ shell which uses SCAN    (Homebase BBS)
CLEANP56.ZIP  -  Removes all known virii                (Homebase BBS)
VSTOP54.ZIP   -  Smaller/compact version of SCANRES (?) (Homebase BBS)

Files are located in pub/ibm-antivirus.  Users may upload files
to pub/ibm-antivirus/00uploads.  All files are scanned and then
ZIPed.  PKZ102.EXE (self-extracting (total) ZIP package) is
available in pub and pub/ibm-antivirus
- ----------

James Ford -  [e-mail], [e-mail]
              University of Alabama in Tuscaloosa.

------------------------------

Date:    19 Jan 90 17:08:58 +0000
From:    Irving Chidsey <[e-mail]>
Subject: Re: Ethical Judgement of the Internet Worm

[e-mail] writes:
<It seems equally clear that this profession does not have sufficient
<integrity to inoke such sanctions.  Though Cornell concluded that he
<did it (and he does not deny it), they have said that he is eligible
<to re-apply for admission to continue his studies.  Other
<"responsible" members of the profession have been willing to employ
<him.  Thus his contemporaries could conclude that, while such actions
<might be in technical violation of the ACM's code, they are not in
<violation of community standards.
<
<If the profession and society are to be protected from such impolite,
<disorderly, and destructive behavior, then we must reach a collective
<conviction we are prepared to consistently support in both
<voice and action.  In the absence of such a concensus, we can expect
<more of the same.
<
<William Hugh Murray, Fellow, Information System Security, Ernst & Young

This raises the questions of appropriate punishment and rehabilitation.

What punishment is appropriate for what he did?

Can he be rehabilitated?  Should he then be employed in the field
Computers?

If not, does this mean that breeding virii is the unforgivable sin?

Or just that although he can eventualy be forgiven, he cannot be
trusted?
                                                                Irv

I do not have signature authority.  I am not authorized to sign anything.
I am not authorized to commit the BRL, the DOA, the DOD, or the US Government
to anything, not even by implication.
                        Irving L. Chidsey  <[e-mail]>

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Monday, 22 Jan 1990    Volume 3 : Issue 17

Today's Topics:

Jury for Morris Trial
Re: Internet worm writer to go to trial Jan 16th. (Internet)
Internet Worm Trial
Internet Worm Trial
Re: Ethical Judgement of the Internet Worm
Internet Worm Trial
Re: Academic Press makes good! (PC)
CLEANP56, SCANV56 and SCANRS56 uploaded to SIMTEL20 (PC)
Universal virus scan.
Re: theoretical virus scanning

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

---------------------------------------------------------------------------

Date:    Fri, 19 Jan 90 15:15:00 -0500
From:    "ROBERT M. HAMER" <[e-mail]>
Subject: Jury for Morris Trial

Irving Chidsey <[e-mail]> writes:

>[e-mail] (Damon Kelley; (RJE)) writes:
>
><Isn't a "jury of his peers" called for here?
><
><      She said that the trial would be more impartial if the jury is
><composed of non-tech persons.  Comments?
>
...   stuff deleted ...
>defense gets more of the latter.  Both sides were probably afraid of
>computer knowledgeble jurors because they know something about
>computers.  Neither side wants experts on the jury, they are too hard
>to sway and lawyers prefer pliable jurors who can be convinced by
>rhetoric.

I have served as an expert witness and consulted for lawyers in
several cases in which statistical expertise was needed.  I will go a
bit further than mr Chidsey:

Lawyers not only do not want 'experts,' they do not particularly want
highly educated people.  They HATE Ph.Ds.  We are unpredictable, and
likely to pay attention to the things we want to attend to rather than
the things the legal system wants us to attend to.  Luckily for
lawyers (and unfortunately for our legal system) most people with
education manage to get themselves excused from jury duty, leaving the
jury pool composed of the unemployed, homemakers, and the retired.

------------------------------

Date:    20 Jan 90 00:49:42 +0000
From:    [e-mail] (Gene Spafford)
Subject: Re: Internet worm writer to go to trial Jan 16th. (Internet)

[e-mail] (Damon Kelley; (RJE)) writes:
>       I just wanted to inform the readers of this list that Robert
>T. Morris of Arnold, Maryland is going to trial this January 16, 1990
>for unleashing (was it "The Great Internet Worm?") a worm that
>immobilized a certain computer network in November of 1988.  Mr.
>Morris is a student who was suspended from Cornell University because
>of his actions.

The trial started January 8.  I believe that all witnesses have been
heard for both sides by now, and the final arguments and charge to the
jury will be made on Monday (the 22nd).  Expect a verdict Monday or
Tuesday -- it's a single count charge and I don't think the jury will
have too hard a time deciding it.

>       When I read the article that I got the above information from,
>I was a bit shocked that the jurors were deliberately picked by the
>U.S. Justice Department lawyers because didn't know *anything* about
>computers.  Would the jurors understand enough of the computer talk
>thrown between defense and prosecutor to reach a truly informed
>verdict?

The reporters (and you) don't understand the situation.  I was there
to testify as a witness and spoke at some length with the prosecutors
and some others associated with the case.

The fact that the jury is composed of people who don't have computer
experience is an artifact of the jury pool and selection process, not
something done on purpose.  The jury pool is dominated by older
people, including many retirees.  Professionals and students are
often excused from jury duty because spending 3 weeks on a jury
might be a real hardship for them.  Plus, Syracuse is not exactly like
Boston or Sunnyvale where you have a high percentage of
computer-literate adults ready to serve.

The prosecution used none of their challenges to strike anyone from
the jury because of their computer use (I was told this by the
prosecutors).  However, the defense MAY have used some of their
challenges to strike computer-literate people from the jury since it
is in their best interest to confuse the jury with jargon and computer
terms.  If the jury cannot understand what happened, they will find it
difficult to decide guilt beyond a reasonable doubt.

>       My mother and I discussed the issue.  I said that the trial
>would be unbalanced and handled badly because every little techie term
>would have to be explained over and over again to the jury, slowing
>down the trial process.  Isn't a "jury of his peers" called for here?

A jury of his peers would be 12 careless hackers with little concern
for other people's ownership of their machines and software.  (Okay,
so we can have a jury of OSF hackers. :-)

>       She said that the trial would be more impartial if the jury is
>composed of non-tech persons.  Comments?

What's impartial?  A jury of little old ladies who all think that Robert
looks like their grandsons would be worse than an otherwise random jury.

>       Does the Justice Department have a prejudice against computer
>enthusiasts?  Perhaps so.  In the article I read, the lawyers excluded
>persons who owned computers, but included persons whose jobs involved
>"pushing buttons," such as flight reservation clerks and insurance
>claim processors.

The reporters don't understand the nuances of jury selection and are
making the wrong conclusions.  And no, the prosecutors do not have
anything against computer enthusiasts at all.  Quite the opposite.

- --
Gene Spafford
NSF/Purdue/U of Florida  Software Engineering Research Center,
Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-2004
Internet:  [e-mail]   uucp:   ...!{decwrl,gatech,ucbvax}!purdue!spaf

------------------------------

Date:    Fri, 19 Jan 90 22:14:00 -0500
From:    [e-mail]
Subject: Internet Worm Trial

>I would remind you that he _allegedly_ unleashed the Internet Worm.
>Innocent before proven otherwise and all that stuff, you know...

Not so.  It is a finding of fact that he released the worm.  It
is alleged that that was a criminal act.  He is guilty of
releasing the worm.  He is innocent of a crime until it is proven
that the act was criminal.

William Hugh Murray, Fellow, Information System Security, Ernst & Young
2000 National City Center Cleveland, Ohio 44114
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840

------------------------------

Date:    Fri, 19 Jan 90 22:42:00 -0500
From:    [e-mail]
Subject: Internet Worm Trial

>This raises the questions of appropriate punishment and rehabilitation.

>What punishment is appropriate for what he did?

The law provides for a fine of up to $250,000 and up to five years in
a Federal penetentiary.  However, this punishment is intended to
protect society from criminal acts.

There is also the issue of the obligation that a postulant to a
profession owes the profession and what requirements the profession
places upon aspirants to the profession.  Most Professions will not
grant credentials to convicted felons.  Neither will they grant
credentials to those that violate the canons of the profession during
their training.  They will will revoke the credentials of those who
violate the canons of the profession.  The professions do this to
protect the reputation of the profession and the integrity of the
credential rather than to punish the violator.

>Can he be rehabilitated?

There seems little doubt that young Morris can be rehabilitated.

>Should he then be employed in the field (of) Computers?

That depends upon where the profession sees its interests.  If he were
an aspiring physician and violated the ethics of Medicine, he could be
employed in medicine but would not likely be granted professional
credentials.

>If not, does this mean that breeding virii is the unforgivable
>sin?

No, only that it is not behavior tolerated by a profession of its
members.

>Or just that although he can eventualy be forgiven, he cannot be
>trusted?

The sanction is not invoked because the individual is no longer to be
trusted, but rather to be sure that the profession is.

William Hugh Murray, Fellow, Information System Security, Ernst & Young
2000 National City Center Cleveland, Ohio 44114
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840

------------------------------

Date:    20 Jan 90 19:11:01 +0000
From:    khijol![e-mail] (Edwin R. Carp)
Subject: Re: Ethical Judgement of the Internet Worm

[e-mail] writes:

>I suspect the conclusion of the authorities at Cornell that young Morris
>acted with "reckless disregard" for the consequences is the closest that
>we will ever get to an ethical judgement about his actions.

[...]

>Of course the ACM does have such a code, and it is likely that young
>Morris has or would subscribe to it.  However, it did not deter him.
>Since his lawyer plans for him to testify, we will likely get to hear
>his rationale for his behavior.  However, I doubt that he seriously
>considered the ethics of his actions until confronted with the
>consequences.

Why is it likely that "young Morris" has or would subscribe to any
moral or ethical code, other than his own?  I find the discussion of
computer ethics particularly amusing, considering the political
posturing, infighting, and one-upmanship games played by so-called
"professionals".  Everyone else, it seems, follows their own ethical
code, so why expect someone else to uphold an ethical code in one
area, while refusing to uphold a similar ethical code in another?

>Had he done so, I am not sure that it would have altered his behavior.
>Like many of his defenders in the net, I suspect that he would have seen
>as ethical, or as not an ethical issue.  There does not seem to be a
>concensus among his contemporaries that that kind of behavior is
>reprehensible.  Neither does there appear to be a concensus among them
>that they have an interest in an orderly playground.

 Who does?  Orderly, perhaps, in one's own viewpoint, which may not
match another's, so can hardly be viewed as a "concensus".

>Note that though Morris aspires to be a professional in the field, and
>is, therefore, subject to professional sanctions, most of his
>contemporaries who use computers have no such aspirations and are not
>subject to such sanctions.

 He is not necessarily subject to professional sanctions, at least not
those as harsh as would be assessed on yourself (or me, for that
matter).  A child is not assessed the same punishment as an adult for
the same crime.  If a man drives his car down the street in a reckless
manner, and in doing so runs over and kills someone, that man is
liable for civil damages as well as severe criminal penalties.  A
child who does the same thing has a much less strict penalty accrued
to him.

The point being a child is still in a learning process, whereas the
adult is assumed to know better (a dangerous assumption, admittedly).

>It seems equally clear that this profession does not have sufficient
>integrity to inoke such sanctions.  Though Cornell concluded that he
>did it (and he does not deny it), they have said that he is eligible
>to re-apply for admission to continue his studies.  Other
>"responsible" members of the profession have been willing to employ
>him.  Thus his contemporaries could conclude that, while such actions
>might be in technical violation of the ACM's code, they are not in
>violation of community standards.

 The Internet is generally regarded as an experimental media for the
proliferation of experimental software and techniques by students (who
are still learning), as well as professionals.  Some of the traffic
carried by the network is of such low quality that one questions the
professionalism of those proliferating such traffic.  However, *their*
integrity is never questioned.

Who can conclude otherwise, when society itself rewards those who "get
away" with moral and ethical "crimes" (and sometimes criminal), while
at the same time punishing those who have the courage to stand up to
those perpetrate such unethical behavior.  I shudder to think what
would happen to my marketability if I were to pursue litigation
against one of the largest employers of computer "professionals" in
this country (litigation that my attorney assures me I would win).  On
the other hand, unethical and downright illegal activities perpetrated
by this same company are ignored and even condoned as "good business
sense".  One can only interpret this to mean that "good business
sense" entails doing anything to make a buck and prevent your
competition from doing so, as long as you don't get caught, and even
then, it's "may the best lawyer win".  It's no longer a case of what
you do, but how you can make it look.

>If the profession and society are to be protected from such impolite,
>disorderly, and destructive behavior, then we must reach a collective
>conviction we are prepared to consistently support in both
>voice and action.  In the absence of such a concensus, we can expect
>more of the same.

I must disagree.  If we held everyone to the same standard of conduct
that you propose, half of the programmers and most of the managers in
the DP arena would immediately lost their jobs.  Even managers, who
should know better, display immature, disorderly, impolite, and
destructive behavior to a much higher degree than does the average
programmer, because their position allows them to escape the
consequences of their childish and irrational behavior.  Even in
academia, such games constantly proliferate.

If we insist on judging others, let us be measured by the standards the we
wish to impost upon others.

If we wish to judge Robert Morris on his behavior and conclude that it
was childish, immature, destructive, impolite, or improper, let us
look to our own ranks and ask ourselves the question: Are we *really*
any better?
- --
Ed Carp                 N7EKG/5 (28.3-28.5)     uunet!cs.utexas.edu!khijol!erc
Austin, Texas           [phone]          "Good tea.  Nice house." - Worf
"The best diplomat I know of is a fully activated phaser bank."  -- Scotty

------------------------------

Date:    Sat, 20 Jan 90 14:44:00 -0500
From:    [e-mail]
Subject: Internet Worm Trial

>I can hardly imagine the software industry ostracising "Young
>Morris" for this offense.  His kind of smarts are worth big, big
>bucks, .....

Perhaps.  However, that is a short term view.  The software industry
is only a few decades old.  Over time their view of their self
interest may change.  Incidentally, critics of the code were not much
impressed with its creativity or quality.

> .......and he is most unlikely to pull this kind of crap on a
>development company's LAN.

That is an interesting assertion.  I would be interested in your
rationale.  It may be similar to that employed by SRI International
when it decided to employ "Dark Dante."

While people often abandon behavior which they find to be
self-destructive, they rarely give up behavior which they perceive as
making them famous or wealthy, or which is otherwise seen as being
valued and rewarded by others.  If you hire someone in spite of
hacking, and for work unrelated to hacking, they may do what you hired
them to do.  However, if you hire them BECAUSE of hacking, and for
work that is related to hacking, you are naive if you expect them to
stop.

Also, the distinction between professional and non-professional work
applies here.  Permitting young Morris to work writing code under
supervision would be one thing.  Employing him to work deciding what
code is to be written, without supervision, and directing the work of
others, might be another.

Since some software has been written as individual effort, some
thought experiments might be useful here.  Given a choice between code
with Ken Norton's name on it and code with Morris's name on it, which
would you choose?  Which do you think the majority of buyers would
choose?  If you were Morris, would you attempt to sell your product
under your own name or a under a psuedonym?

William Hugh Murray, Fellow, Information System Security, Ernst & Young
2000 National City Center Cleveland, Ohio 44114
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840

------------------------------

Date:    Fri, 19 Jan 90 21:52:11 +0000
From:    Carolyn M. Kotlas <[e-mail]>
Subject: Re: Academic Press makes good! (PC)

Subject: Re: Academic Press makes good! (PC)

In article <[e-mail]>, [e-mail]
writes:
> I'm not sure why it took them so long, but at least AP is taking
> responsibility.  I imagine their senior executives are holding
> their aching heads and wondering why they decided to enter the
> software publishing business.  Books never require product recalls.
                                 ^^^^^ ^^^^^ ^^^^^^^ ^^^^^^^ ^^^^^^^
Not so! Microsoft Press had to recall their first edition of the
MS-DOS Encyclopedia due to an embarrassingly large number of errors.
We had to get authorization from the publisher to send our copy back
and qualify for a replacement copy.  (Couldn't just send back the
manual's title page to prove our legal ownership.) It was about a year
(and several phone calls) before we finally got our non-beta edition
of this book.

Carolyn Kotlas                      ([e-mail])
UNC-Educational Computing Service   P. O. Box 12035          2 Davis Drive
Research Triangle Park, NC  27709   State Courier #59-01-02  919/549-0671

------------------------------

Date:    Fri, 19 Jan 90 12:27:00 -0700
From:    Keith Petersen <[e-mail]>
Subject: CLEANP56, SCANV56 and SCANRS56 uploaded to SIMTEL20 (PC)

Yesterday I announced new versions of McAfee Associates' anti-virus
programs.  Today I received updates and they are now on SIMTEL20.
These files were obtained from the HomeBase BBS.

pd1:<msdos.trojan-pro>
CLEANP56.ARC    Universal Virus disinfector, heals/removes
SCANRS56.ARC    Resident virus infection prevention program
SCANV55.ARC     VirusScan, scans disk files for 61 viruses

 --Keith Petersen
Maintainer of SIMTEL20's CP/M, MSDOS, & MISC archives [IP address 26.2.0.74]
Internet: [e-mail], [e-mail]  BITNET: w8sdz@NDSUVM1
Uucp: {ames,decwrl,harvard,rutgers,ucbvax,uunet}!wsmr-simtel20.army.mil!w8sdz

------------------------------

Date:    Fri, 19 Jan 90 19:56:06 -0400
From:    GEORGE SVETLICHNY <[e-mail]>
Subject: Universal virus scan.

In Virus-L V3 No 15, Dave Myers (mummy![e-mail]) expreses
a doubt about Vesselin's ([e-mail]) proof of the
impossibility of a universal virus detector(Virus-L V3 No 13):

> I may be missing something, but it seems the above program makes the
> assumption that A cannot detect some virus.  If A can detect all
> virisus then P1 will in fact be unable to infect another program and
> is thus not a virus.
>
> dave

You're not missing anything Dave, it'p precisely the *assumption* that
A detects all viruses that is shown to be untenable, and so no such
algorithm can exist. Reductio-ad-absurdum pure and simple. Think of it
this way: your friend *claims* he has a universal virus detector A.
You write Vesselin's program P1, and give it to your friend. He runs A
on it. If A say "O.K" you invite him (grinning) to run P1 on his
machine.  If A says "Virus" you run P1 on *your* machine (also
grinning). In any case A was fooled.

The same type of informal proof can be used to show the impossibility
of an algoritm to say if a program will stop or not. Let now A(P) mean
"program P will stop" and write the program

        Program P2
        begin
           if A(P2)
             repeat
             while TRUE
           else
             exit
        end


A very simple argument and very powerful.

George Svetlichny   [e-mail]

/\/\/\/\/\/\/\ (Waves on Copacabana beach, its 40 Centigrade here).

------------------------------

Date:    20 Jan 90 04:18:17 +0000
From:    [e-mail] (Kelly Goen)
Subject: Re: theoretical virus scanning

All proofs aside on a practical level... it is possible with memory
protection architectures to defend totally(well at least 99% of the
time) against intrusion by infectious processes...I speak from
REAL-LIFE experience here... so all these great proofs again theory
and real-life do not match or perhaps the theory is a CROCK of
S____!!the remaining 1 % are easily caught by an informed and
knowledgable user....I for one am not going to give up and claim its
impossible to detect all viruses..... flames >/dev/null
     cheers
     kelly
p.s. when your conclusions appear to be in error check your premises...

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Tuesday, 23 Jan 1990    Volume 3 : Issue 18

Today's Topics:

Re: Internet worm writer to go to trial Jan 16th. (Internet)
the Internet Worm trial
Internet Worm
Internet Worm Trial
Internet Worm Trial (Ethics)
Internet Worm Trial
Re: Jury for Morris Trial
Internet Worm Trial

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

---------------------------------------------------------------------------

Date:    22 Jan 90 19:17:56 +0000
From:    [e-mail] (Gordon D. Wishon)
Subject: Re: Internet worm writer to go to trial Jan 16th. (Internet)

[e-mail] (Gene Spafford) writes:

>The reporters (and you) don't understand the situation.  I was there
>to testify as a witness and spoke at some length with the prosecutors
>and some others associated with the case.

Gene, in your report (_The Internet Worm Program:  An Analysis_), you
speculated that the code may have been written by more than one
person.  Has anything come out in the trial to support this?


------------------------------

Date:    Mon, 22 Jan 90 10:12:20 -0500
From:    EASTRA@morekypr
Subject: the Internet Worm trial

interesting how all the computer experts on this list are legal
experts as well since the posters to the list have already convicted
the defendent, they would clearly be ideal jurors after all, guilty
until proven innocent is clearly the attitude here

- -- ray easton


------------------------------

Date:    Mon, 22 Jan 90 00:00:00 +0000
From:    "Prof Arthur I. Larky" <[e-mail]>
Subject: Internet Worm

             Just a few comments on the Internet Worm and Mr.  Morris:

             The  number  of  challenges  available in Federal Court are
        more limited than those we have been led to expect from watching
        Perry Mason.  I just finished testifying in  a  patent  suit  in
        which  one  of the jury members was an inventor with a patent of
        his own.  He was not challenged even though it might  have  been
        better to have persons with no knowledge of patents or the field
        of  the  patent  on  the jury.  Juries are supposed to decide on
        FACTS,  which  depends  more  on   their   evaluation   of   the
        truthfulness  of  witnesses  than on the technical material.  In
        Morris' case, the jury probably has to decide on things such  as
        willfulness and whether the actions are proscribed under Federal
        laws.

             One  of the objections to "knowledgeable persons" on a jury
        is that they might stampede the jury  to  a  hasty  decision  by
        insisting that they understand the matter "better".  Lawyers use
        expert witnesses in an attempt to give the jury an understanding
        of  the  consequences  of the disputed facts.  I suspect that it
        really boils down to credibility  -  which  of  the  conflicting
        opinions does the jury believe?

             IMHO  if  all Morris wanted to do was to try out a worm, he
        could have isolated Cornell from  Internet  and  infected  their
        university-wide Ethernet LAN.  It would have been just as good a
        test   and   would   not   have   crashed   the  whole  country.
        Alternatively, he could have asked for permission to do a formal
        experiment on Internet; in which case, Internet sites could have
        protected themselves from a major  crash  and  would  have  been
        pre-warned of the steps to take to stop the beast.  Morris acted
        irresponsibly  and deserves to face the consequences of his acts
        just as a person which is accused of manslaughter has to face  a
        jury  and  possible  consequences.   No  doubt he is ready to be
        rehabilitated  since  he  seems  not  to  have  considered   the
        consequences  of  his  actions.   Without  having  heard all the
        evidence, I cannot make a judgement, so we have to wait and  see
        what the jury decides.  It would be interesting to know what was
        the charge to the jury; that is, what facts were they to decide?

             Obviously, these are my opinions, not those of my employer.


        Art Larky
        Professor of Electrical and Computer Engineering
        Computer Science and Electrical Engineering Department
        Lehigh University

















------------------------------

Date:    22 Jan 90 22:49:52 +0000
From:    [e-mail] (Frederick L. Crabbe)
Subject: Internet Worm Trial

>>Can he be rehabilitated?
>
>There seems little doubt that young Morris can be rehabilitated.

Just a note: I found out from a rather reliable source that our friend
Morris infected the AT&T Bell Labs system when he was a high school
student.  They responded by hiring him for the summer.  So much for
one attempt of rehabilitation.

- -ric

- --
'I didn't know you had a perfect ass until you walked away.  Forgive me for not
falling in love with your face or your conversation.'
                                                       -Leonard Cohen
[e-mail]

------------------------------

Date:    Mon, 22 Jan 90 19:21:00 -0500
From:    [e-mail]
Subject: Internet Worm Trial (Ethics)

Ed Carp                 N7EKG/5 (28.3-28.5)     uunet!cs.utexas.edu!khijol!erc
Austin, Texas           [phone]

Writes:

>I must disagree.  If we held everyone to the same standard of conduct
>that you propose, half of the programmers and most of the managers in
>the DP arena would immediately lost their jobs.

It has not been my intention to propose any standard of conduct,
but rather to compare a particular piece of behavior to
alternative but possible standards.

>Everyone else, it seems, follows their own ethical
>code, so why expect someone else to uphold an ethical code in one
>area, while refusing to uphold a similar ethical code in another?

Indeed, they do not.  Most people behave in an orderly and polite
manner most of the time, at least to the extent that there is a
concensus about what it is.  What is at issue here is can we
reach one.

>He is not necessarily subject to professional sanctions, at
>least not those as harsh as would be assessed on yourself (or
>me, for that matter).

Clearly.

>A child is not assessed the same punishment as an adult for
>the same crime.  If a man drives his car down the street in a
>reckless manner, and in doing so runs over and kills someone,
>that man is liable for civil damages as well as severe criminal
>penalties.  A child who does the same thing has a much less
>strict penalty accrued to him.

Well it is certainly an interesting defense, but I doubt that
young Morris would subscribe to it.  In the case of the
automobile and the child, there is a presumption of ignorance,
lack of skill, and immature judgement.  While I grant that there
is evidence of all three things here, a twenty-four year old
doctoral candidate is not presumptively entitled to them.

>Even managers, who
>should know better, display immature, disorderly, impolite, and
>destructive behavior to a much higher degree than does the average
>programmer, because their position allows them to escape the
>consequences of their childish and irrational behavior.

However, we are not talking about all such behavior, but rather
that which may be in violation of legal or professional
standards.

>The Internet is generally regarded as an experimental media for
>the proliferation of experimental software and techniques by
>students (who are still learning), as well as professionals.

Nice people do not blot other peoples' copy books or interfere
with their experiments.  We do not tolerate students who trash
laboratories simply because they are students.  Indeed, one of
the things that we explicitly judge about a student is whether of
not he can be sufficiently socialized to be fit to work with.

>Some of the traffic carried by the network is of such low
>quality that one questions the professionalism of those
>proliferating such traffic.  However, *their* integrity is never
>questioned.

No doubt, but beside the point.  It is not the quality of the
traffic that is at issue here, but the purpose.  Morris may have
written the best code that he was capable of.  His ONLY defense
is that it was only an offense of poor quality.  That had it
performed as he intended it too, HE WOULD NOT HAVE BEEN CAUGHT.
Nonetheless, the code was risky at best and it never had a
legitimate purpose.

>If we insist on judging others, let us be measured by the standards the
>wish to impost (sic) upon others.

First,I have tried to avoid judging the individual and stick to
commenting upon the behavior.   Second, it is not my intention to
impose a standard of behavior, but rather to compare the behavior
to traditional norms.  Finally, I fully expect that abherent
behavior on my part is likely to be held to far more arbitrary
standards than those which I am trying to discuss here.  I will
not like it, but I can live with it.

I doubt that either the Justice Department or the profession take
any delight in having been put in the position where there is any
behavior to judge.  I certainly do not.

William Hugh Murray, Fellow, Information System Security, Ernst & Young
2000 National City Center Cleveland, Ohio 44114
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840

------------------------------

Date:    Tue, 23 Jan 90 08:14:00 -0500
From:    [e-mail]
Subject: Internet Worm Trial

Mr. William E. Johnston, a computer manager at LBL is quoted by John
Markoff in today's NY Times as saying "An appropriate sentence would be
public service in the field of computing."

Would this be punishment?

Would it deter others?

Would it be rehabilitative?

Anybody want to join me in nominating LBL as the place for such service?

How say you?

William Hugh Murray, Fellow, Information System Security, Ernst & Young
2000 National City Center Cleveland, Ohio 44114
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840

------------------------------

Date:    Tue, 23 Jan 90 15:13:36 +0000
From:    [e-mail] (Evelyn C Leeper)
Subject: Re: Jury for Morris Trial

[e-mail] (ROBERT M. HAMER) writes:
> lawyers (and unfortunately for our legal system) most people with
> education manage to get themselves excused from jury duty, leaving the
> jury pool composed of the unemployed, homemakers, and the retired.

I'm sure this is a slip of the keyboard here, since I know many educated
unemployed people, homemakers and retired people.

Evelyn C. Leeper  |  [phone]  |  att!mtgzy!ecl or  [e-mail]
- --
If I am not for myself, who is for me?  If I am only for myself what am I?
And if not now, when?  --Hillel

------------------------------

Date:    Mon, 22 Jan 90 21:29:14 -0500
From:    Bridget Rutty <[e-mail]>
Subject: Internet Worm Trial

Morris has been convicted.

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Tuesday, 23 Jan 1990    Volume 3 : Issue 19

Today's Topics:

UNCONFIRMED Virus on VAX (VAX/VMS)
Re: theoretical virus scanning
Re: Internet worm writer to go to trial Jan 16th. (Internet)
BITFTP files also on SIMTEL20
Requests/Questions (PC)
The universal virus scanner
Eradicat'Em 1.0. Is is safe?? (Mac)
WDEF infection (Mac)
Warning of WDEF A Infection... (Mac)
WDEF A infection followup (Mac)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

---------------------------------------------------------------------------

Date:    Mon, 22 Jan 90 10:16:00 -0400
From:    The Man with the Plan <[e-mail]>
Subject: UNCONFIRMED Virus on VAX (VAX/VMS)

>From:  IN%"[e-mail]"  "Vax discussion" 21-JAN-1990 23:11:59.77
>Subj:  <Vax 85> Virus on VAX
>From: [e-mail]

>        Hi!

>        Dose anyone have a idea about VAX Virus? Or interesting on
>        it? I think the most difficult point is how to spread it
>        out. So if someone has any bright idea, contact with me.

>                                                James Huang

        Here is a message from UMNews's Vax discussion list.  I
thought the list should know about this.  The node is Taiwanese.

------------------------------

Date:    22 Jan 90 00:00:00 +0000
From:    "David.M..Chess" <[e-mail]>
Subject: Re: theoretical virus scanning

[e-mail] (Kelly Goen) writes:

> All proofs aside on a practical level... it is possible with memory
> protection architectures to defend totally(well at least 99% of the
> time) against intrusion by infectious processes...I speak from
> REAL-LIFE experience here...

But when you speak from "REAL-LIFE experience", all you can talk about
is experience with the viruses that have been written so far, yes?
The viruses we've seen so far are, compared to what's possible,
awfully simple.  I'd suggest being a tad less confident, myself!
Surely you can think of a virus or worm that could sneak past your
defenses?

(As an aside, I'm not sure I understand the reference to "memory
protection architectures"; even the current virus technology doesn't
have to rely on unprotected *memory* (although some viruses do). The
thing that would help most against the current sorts of viruses, it
seems to me, is better file-access-control.  Of course, to implement
that reliably, you do need memory protection, but memory protection by
itself doesn't buy you much, anti-virus wise.)

On the other hand, I do agree that the theoretical proof is of limited
interest.  It shows that you can't detect viruses with 100% accuracy.
But the interesting question is "can we detect them with -acceptable-
accuracy, and if so, how much will it cost?"

DC

------------------------------

Date:    23 Jan 90 17:28:23 +0000
From:    [e-mail] (Gene Spafford)
Subject: Re: Internet worm writer to go to trial Jan 16th. (Internet)

Sigh.  I mistyped.  My apologies.

[e-mail] (Gene Spafford) writes:
>A jury of his peers would be 12 careless hackers with little concern
>for other people's ownership of their machines and software.  (Okay,
>so we can have a jury of OSF hackers. :-)

I meant FSF, not OSF.

Repeat after me,
  OSF is not FSF
  OSF is not FSF


BTW, at 9:30 pm last night the jury returned a guilty verdict against
young Mr. Morris.   The sentencing hearing is Feb. 27.   Federal
sentencing guidelines would dictate a mandatory jail sentence of (as I
remember) 12 months.  The judge in the case has a reputation of going
light on "white-collar" crime sentencing, however, and I suspect we
will see a fine, probation, and a suspended sentence.

- --
Gene Spafford
NSF/Purdue/U of Florida  Software Engineering Research Center,
Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-2004
Internet:  [e-mail]   uucp:   ...!{decwrl,gatech,ucbvax}!purdue!spaf

------------------------------

Date:    Mon, 22 Jan 90 14:52:24 -0500
From:    Peter Jones <[e-mail]>
Subject: BITFTP files also on SIMTEL20

On Fri, 19 Jan 90 15:38:07 EST The Moderator Kenneth R. van Wyk said:
>VIRUS-L Digest   Friday, 19 Jan 1990    Volume 3 : Issue 16
>BitNet *can* FTP now.....
>Internet Worm Trial
>------------------------------
>
>Date:    Fri, 19 Jan 90 10:28:53 -0600
>From:    James Ford <[e-mail]>
>Subject: New files (PC)
>
>The following files have been added to MIBSRV.MIB.ENG.UA.EDU
>(130.160.20.80):
[text deleted]
>
>James Ford -  [e-mail], [e-mail]
>              University of Alabama in Tuscaloosa.

The same files are available from SIMTEL20.

Peter Jones     MAINT@UQAM     (514)-987-3542
"Life's too short to try and fill up every minute of it" :-)

------------------------------

Date:    Tue, 23 Jan 90 00:21:04 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Requests/Questions (PC)

Nothing important this time...just a few virus-related items.

1) I found this text inside the W13 virus. Can anybody translate it ?
   Please send the translation to me ([e-mail]), not to the list.

             Program typu COM nie robi?cy absolutnie nic.
             Jego przeznaczeniem jest;
             wystawianie si? na wabia wirusom.

2) The "Palette" virus has been reported to be 1538 bytes long. Can anybody
   confirm that ?  The reported identification string matches my copy of
   "Zero Bug" which has an infective length of 1536 bytes. Either we have
   two variants or the "1538" may just be an error. Besides - 1536 is a much
   nicer number - it turns out as 11000000000 in binary.... :-)

3) I have found two (very minor) bugs in my F-PROT package - one program
   does not display a start up message and another may display a help message
   in Icelandic instead of English. I will correct this in the next release.

4) And yes, if Roy Silvernail happens to read this - could you please E-Mail
   me again - I lost your original message before I could reply.

- -frisk

------------------------------

Date:    Tue, 23 Jan 90 10:25:04 +0000
From:    "Dr. A. Wood" <[e-mail]>
Subject: The universal virus scanner

A contribution to the universal virus scanner controversy.

On 17 Jan 90 15:07:00 +0700, [e-mail] wrote:
"Construct the program Q thus:
   program Q; begin
   if is_a_virus(Q) then (* do nothing *) else infect_other_programs;
   end.

On 19 Jan 90 19:56:06 -0400, GEORGE SVETLICHNY <[e-mail]>
wrote:- "The same type of informal proof can be used to show the
impossibility of an algorithm to say if a program will stop or not.
Write the program
   program R; begin
   if will_stop(R) repeat while TRUE else exit;
   end
A very simple argument and very powerful.".

These are versions of the ancient paradox which comes in various forms:-
(1) Statement (1) is untrue.
(2) Jack said "Everything I say is a lie.".
(3) The set of all (sets which are not members of themselves): is it a member
    of itself?

What will probably happen will be that program Q or R will # examine
itself by going through all its code, including the instruction to
examine itself - repeat from # forever. Probably both Q and R will get
into infinite recursion when used to examine themselves, but may well
behave correctly when examining ordinary programs which are not
themselves program-checkers. When examining themselves, Q and R yield
neither YES nor NO, but simply crash.

{A.Appleyard} (email: [e-mail]), Tue, 23 Jan 90 09:36:12 GMT

------------------------------

Date:    Tue, 23 Jan 90 14:20:36 +0000
From:    [e-mail] (Glenn P Hoetker)
Subject: Eradicat'Em 1.0. Is is safe?? (Mac)

I remember, dimly, seeing warnings right after WDEF surfaced about the
Eradicat'Em Init, mainly that it was unstable.  Now that I have that init
and am responsible for protecting two public Macs, I can't find those
articles, of course.  So, with apologies for bringing it up again, is
Eradicat'Em 1.0 a safe, stable, and effective way to combat WDEF?  Please
e-mail versus cluttering the board with old news.  Thank you much in
advance.

Glenn Hoetker  ([e-mail])
Macintosh Resource Person
GSLIS/LRL
University of Illinois

- --
Glenn Hoetker
University of Illinois, Graduate School of Library and Information Science
[e-mail]     -or-   ghoetker@UIUCVMD

------------------------------

Date:    Tue, 23 Jan 90 11:20:00 -0600
From:    Ken De Cruyenaere 204-474-8340 <[e-mail]>
Subject: WDEF infection (Mac)

Reports of WDEF infections on our campus are coming in.
Gatekeeper aid is being used to fight it.
- ---------------------------------------------------------------------
Ken De Cruyenaere - Computer Security Coordinator
Computer Services - University of Manitoba - Winnipeg, Manitoba, Canada, R3T 2N
2
Bitnet: [e-mail]               [phone]

------------------------------

Date:    Sat, 20 Jan 90 23:37:37 -0500
From:    [e-mail] (David Gursky)
Subject: Warning of WDEF A Infection... (Mac)

[Ed. From VALERT-L - see related message (below).]

There is a new Macintosh application coming on the market now, called
Grammitik.  I understand from a friend of mine who works at a local outlet of
Egghead Software that the copies they received have been infected with WDEF A.
I have not confirmed this myself, but I have the utmost faith in Andy's
ability and believe the report to be accurate.  By the same token, neither
Andy or I believe this is a deliberate attempt by the publishers of
Grammatik to infect computers, but simply an error.

If you buy or have bought a copy of Grammatik, use Disinfectant, SAM, or any
of a number of known applications that can removed WDEF, on the Master Disk to
sanitize the disk.

Andy's original message has been forwarded to Virus-L.  Any information in it
supersede's what I have written here, from memory.

David Gursky

------------------------------

Date:    Fri, 19 Jan 90 17:35:38 -0500
From:    [e-mail] (David Gursky)
Subject: WDEF A infection followup (Mac)

Given all the messages regarding shrink-wrapped virus, I thought the following
message would be of interest to readers:

[From the Twilight Clone BBS in Washington DC.]

 From:  ANDREW SOLMSSEN           Sent: 01-18-90 23:37
   To:  PAUL COZZA                Rcvd: -NO-
   Re:  SHRINKWRAPPED VIRUSES

Paul, this might interest you:  The first shipment of a new
package for the Mac, Grammatik Mac, that we received at Egghead
last week was infected with WDEF A.  SAM 1.4 had no trouble in
in identifying and eradicating the infection.  I did not get a
chance to try Intercept, but the Clinic performed admirably.
Thought the notion of shrinkwrapped viruses might interest you.

[End of Twilight Clone message.]

Needless to say, this type of infection would be immune to the type of
protection scheme I suggested several days ago.  Also needless to say, this
type of infection would be immune to the counter-proposals had it occured
two months ago, before WDEF was isolated.

Also, this type of infection would be immune to the type of proposal Bill
Murray made several days ago.

In short, there is no single solution to the problem of shrink-wrapped
viruses, no "magic bullet".  Until systems are introduced that are explicitly
user hostile to viruses (and those systems may be a long way off), (1) the
problem of shrink-wrapped viruses is here and here to stay and (2) the
procedures needed to combat it are time-consuming and expensive.  If you cut
corners, you increase the risk of spreading a virus through shrink-wrapped
software.


------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Tuesday,  2 Jan 1990    Volume 3 : Issue 2

Today's Topics:

Network server infections (PC)
December 24. virus (PC)
December 24th virus (PC)
Bug in Virus Buster 1.10 (PC)
Viruses Rhyme And Reason
DIRTYD9C.ARC - The Dirty Dozen List #9C (Trojan/Virus/Pirate)
Yankee Doddle (no system given)
Re: Stoned Virus Killer (PC)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

---------------------------------------------------------------------------

Date:    Wed, 27 Dec 89 12:13:37 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Network server infections (PC)

I received a note in the mail recently asking about viruses infecting network
file servers. Since the reply might be of general interest, I am also posting
it here.

Boot sector viruses will not spread via the network, but most program viruses
are able to do so, under certain circumstances.

Assume we have two users, A and B connected to the network. 'A' runs by
accident an infected program. The virus (assuming it is not of the Direct
Action type) will stay resident and monitor the execution of other programs.
Now, if 'A' runs a (non-infected) program located on the network server, the
virus will try to infect it as it is executed.

If the network software is able to make the files read-only or execute-only
and the user can not change that with an ATTRIB -R command, the virus will
not be able to infect the programs on the server.

However, if 'A' is the supervisor or somebody else with write access, the
virus will be able to infect the programs on the server. Later, when 'B' runs
an infected program from the server, his machine will be infected and also the
programs located there.

- -frisk

------------------------------

Date:    Wed, 27 Dec 89 12:31:36 +0000
From:    Fridrik Skulason
Subject: December 24. virus (PC)

On December 24. several PCs here in Iceland refused to run any programs,
displaying the message "Gledileg Jol" instead. On Dec. 25th everything was
back to normal.

This seems to be a new .EXE infecting virus of Icelandic origin, possibly a
variant of the Icelandic-1 virus.

A full description will be posted as soon as I receive a sample.

- -frisk

------------------------------

Date:    Thu, 28 Dec 89 01:34:33 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: December 24th virus (PC)

I just received a sample of the "December 24th" virus I reported on
VALERT-L earlier today. As I suspected, the virus is just a new
variant of the Icelandic virus, or rather a variant of Icelandic-2.

The major changes I have seen are:

        The virus length is now 848-863 bytes

        If an infected program is run on December 24th, any attempt to
        run another program later that day will just produce the message
        "Gledileg Jol" (Icelandic for "Merry Christmas").

        The creation date of infected files is not changed.

        A few NOP instructions have been added.

Apart from this, the virus seems very similar to Icelandic-2. (Infects only
.EXE files, only 1 out of 10, bypasses INT 21 etc.)

More details later, when I have had the time to disassemble the entire virus.

- -frisk

------------------------------

Date:    Thu, 28 Dec 89 13:20:24 +0200
From:    "Yuval Tal (972)-8-474592" <[e-mail]>
Subject: Bug in Virus Buster 1.10 (PC)

I would like to report about a bug that was found in Virus Buster 1.10.

Virus Buster will not remove some EXE viruses from the file. Instead,
it would make them unavailable. The new version of Virus Buster will
be released soon with those bugs fixed.

Truly sorry,

Yuval Tal
Author of Virus Buster

+--------------------------------------------------------------------------+
| BitNet:   NYYUVL@WEIZMANN        Domain: [e-mail] |
| InterNet: [e-mail]                        |
+----------------------+---------------------------------------------------+
| Yuval Tal            | Voice:   [phone]  (In Israel: 08-474592)    |
| P.O Box 1462         | BBS:     [phone] * 20:00-7:00 * 2400 * N81  |
| Rehovot, Israel      | FidoNet: 2:403/136                   (CoSysop)    |
+----------------------+---------------------------------------------------+
|  "Always look on the bright side of life" *whistle*  -  Monty Phython    |
+--------------------------------------------------------------------------+

------------------------------

Date: 28 Dec 89 05:07:36 GMT
From: [e-mail] (Bill Weston)
Subject: Viruses Rhyme And Reason

I'm not sure that writing viruses will ever stop.

Ross Greenberg wrote perhaps the best psychological profile of the
"virus programmer" that I have ever read.  (It's in the docs of
FLUSHOT, you've all read it...)

 The virus writer likes causing damange.  He thinks it's funny and makes him
feel powerful.  You can bet that most of them are reading what is written
here.  Just look at the worldwide scope of the current AIDS virus scam.  To
this day, tha STONED virus still infects thousands of systems all over the
world.  (Poorly written as it is..)

The target of many virus writers are the millions of PC users who don't know
much about computers.  The novice user, or perhaps the user who knows how to
run programs but does not know much about DOS, is the primary mark.  A friend
of mine was just such a person.  Less than 20 days after buying his PC he was
hit by the STONED virus.  He did not know how to protect himself.  Lots of
grins for the programmer.

There will always be socially retarded morons to write virus programs.  There
is only one way to stop them - cold.  Forums such as this. It is possible that
this very ECHO stopped and cured the AIDS virus...  I wonder how many
thousands of PC users did not install that "program" thanks to what they read
here.

 ---- REMEMBER ----  There is *NO* better protection than FULL AND ADEQUATE
BACKUPS!!!!!

Bill Weston == ...!usceast!uscacm!12!Bill.Weston

------------------------------

Date:    Fri, 29 Dec 89 15:04:00 -0700
From:    Keith Petersen <[e-mail]>
Subject: DIRTYD9C.ARC - The Dirty Dozen List #9C (Trojan/Virus/Pirate)

I have uploaded the latest version of Eric Newhous' "Dirty Dozen List"
to SIMTEL20:

pd1:<msdos.trojan-pro>
DIRTYD9C.ARC    The Dirty Dozen List #9C (Trojan/Virus/Pirate)

- --Keith Petersen
Maintainer of SIMTEL20's CP/M, MSDOS, & MISC archives [IP address 26.2.0.74]
Internet: [e-mail], [e-mail]  BITNET: w8sdz@NDSUVM1
Uucp: {ames,decwrl,harvard,rutgers,ucbvax,uunet}!wsmr-simtel20.army.mil!w8sdz

------------------------------

Date:    Sun, 31 Dec 89 18:18:15 +0000
From:    [e-mail]
Subject: Yankee Doddle (no system given)

Hi,
Could somebody send me information about the YANKEE DODDLE virus, and
a disinfector,
Thanx in advance

M.O. FADEL                    [e-mail]
Bristol University
Comp Sci Dept. (UK)

------------------------------

Date:    31 Dec 89 01:12:00 +0000
From:    munnari!softway.sw.oz.au![e-mail]
Subject: Re: Stoned Virus Killer (PC)

Well for floppy disks there is a program to rewrite boot sectors
and its called  sys.com try reading you dos manuals. If the disk
does not have room for a system use debug
L 0 0 0 1
        to read a clean boot sector from disk in drive A
W 0 1 0 1
        to write over the infected disk in drive B note the disk can
be a non bootable disk ie no system and still have the virus on it. ie
even if you boot it and it reports no system on disk please insert dos
disk , it has loaded the virus in memandy and infected your harddisk
(if you have one). If you have an infected harddisk get either norton
disk doctor or McFee's virus software.

        mark

------------------------------

End of VIRUS-L Digest
*********************
VIRUS-L Digest   Wednesday, 24 Jan 1990    Volume 3 : Issue 20

Today's Topics:

Re: Universal virus scan.
Re: theoretical virus scanning
Morris hacking Incidents...
Innocent until....
Re: Shrink-Wrapped Software
re: Requests/Questions (PC)
Re: WDEF at University of Oregon (Mac)
The STONED Virus (PC)
Re. Universal virus scans
Re: Eradicat'Em 1.0. Is is safe?? (Mac)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

---------------------------------------------------------------------------

Date:    24 Jan 90 08:34:00 EST
From:    [e-mail] (Kenneth R. van Wyk)
Subject: Editor's note/thanks

This digest (or group of Usenet postings) was edited in the public
access terminal room graciously provided at the Usenix conference.
Thanks to the Usenix folks who provided this wonderful service!

Ken

------------------------------

Date:    23 Jan 90 17:03:32 +0000
From:    [e-mail] (Russell McFatter)
Subject: Re: Universal virus scan.

Before proceeding further with the discussion on "disprovable" antiviral
tools, I think we should clear up some misconceptions about the analogy
with the halting problem.  Namely:

(1)  The "halting problem" proof does not apply to finite-state machines
     (proof of this in a moment).  Every machine that we have today IS a
     finite-state machine.  The "halting problem" proof works only on a
     "theoretical" machine with an unlimited number of different states
     (unlimited memory).

     We CAN write a program to determine if a given FINITE machine will halt.
     To do this, we trace the execution on the target machine, and record
     the state of the machine.  If we have seen this state before, the target
     program will never halt (we are in a loop).  If the target machine halts
     first, then the program will halt.  Since the target machine is finite,
     exactly one of these MUST happen eventually.  (no mention of
     performance issues here: this is only a proof!)

     This implies, of course, that the system performing the test is
     substantially larger than the machine (program) being tested.  For this
     reason, the "halting problem" proof cannot be used here.

(2)  Application of the proof to virus detection doesn't make straightforward
     sense.  The purpose of a virus detector is not to determine if a
     particular program will infect others in one particular instance, but
     if it will EVER (under any circumstances) exhibit viruslike behavior.
     All things considered, we can actually write a program that, given
     a questionable bit of code, can give one of the following results:

     OK:  this program is safe and will not infect other applications.
     BAD:  the target program could, under some unknown circumstances,
           modify other applications.
     INCONCLUSIVE:  The target program either modifies executable code or
          executes variable data.

     Applying the "halting-" proof here doesn't work.  If we modify the
     virus-checker so that the "OK" result causes the virus-checker to act
     like a virus, and then apply the virus-checker to itself, it should
     return "BAD" every time.  If we encrypt the virus code, the result should
     read "INCONCLUSIVE".  (I'm ignoring the action of the virus itself here).
     All we care is that the viral-infection code exists, whether or not it
     actually gets executed.  We treat any conditional as if execution
     might proceed down either branch, and complain if the code changes
     itself, or attempts a "write" that we have decided is privileged.
     We do not "strictly" trace execution (i.e. we "prune" branches to
     code we have already examined).

Note that the condition of "modifying other applications" is merely one
of many that could theoretically be implemented with a similar strategy.
Such a program could also find things like trojan horses.  It cannot
prove that a given application contains a virus, or that it is harmful.
Certain programs (the OS itself) would certainly give false "BAD" warnings.
It would allow us to "prove", however, that a given application cannot
cause (certain types of) harm in particular ways; and we should be able to
expect that most normal software is "OK".  We can insist (and it's probably
a good idea!) that applications that we buy do not use self-modifying
code (thus avoiding the INCONCLUSIVE result, which could hide a virus).

Obviously there are other complications, such as handling of overlays,
interrupts, memory, and system calls, but that's more of a technical
issue.

- --- Russell McFatter  [[e-mail]]
std. disclaimer applies.

------------------------------

Date:    23 Jan 90 20:33:43 +0000
From:    [e-mail]
Subject: Re: theoretical virus scanning


In article <[e-mail]>,
[e-mail] (Kelly Goen) writes:
> [stuff deleted]
> ....I for one am not going to give up and claim its
> impossible to detect all viruses..... flames >/dev/null
>      cheers
>      kelly
> p.s. when your conclusions appear to be in error check your premises...

I think there are two related questions which are improperly treated as
one, thereby leading to apparent disagreement.

1. Is there an algorithm which tells if a program is a virus or not?

Formally, is there a computable function which returns the value True
if the argument is a program which will infect other programs,
AND FALSE OTHERWISE?

The answer is no, as seen by the informal proof in a previous article.

2. Is there an algorithm which detects all viruses?

Formally, is there a computable function which returns the value True
if the argument is a program which will infect other programs,
AND MAY RETURN THE VALUE TRUE IN SOME OTHER CASES?

The answer is yes; the function that returns True for all arguments
is an example of an algorithm which detects all viruses.

Of course, a "virus detector" that reports every program as infected
is downright silly, but it seems plausible that a totally virus-proof
system could be built, at least in principle, by carefully designing
both hardware and software.  (In priciple, a totally bug-free operating
system could be created, yes...)  An inevitable drawback of such a system
would be that some perfectly innocent programs would not run under it.
For example, a program which used as temporary storage the file which
contains the memory-resident portion of the operating system, then
copied its original contents from memory to disk, might be unusable ;-)

Yes, practical virus fighting is possible, and the formal undecidability
proofs do not contradict that.

Taneli Huuskonen                [e-mail]
Dept of Mathematics
University of Helsinki          I think myself, therefore I disclaim
Hallituskatu 15
SF-00100  Helsinki
FINLAND

If you disagree about the answers, check the questions as well.

------------------------------

Date:    Tue, 23 Jan 90 14:36:08 -0500
From:    [e-mail] (John McMahon )
Subject: Morris hacking Incidents...

Just to clarify...

***> From:    [e-mail] (Frederick L. Crabbe)
***>
***> Just a note: I found out from a rather reliable source that our friend
***> Morris infected the AT&T Bell Labs system when he was a high school
***> student.  They responded by hiring him for the summer.  So much for one
***> attempt of rehabilitation.

The following is quoted (without permission) from John Markoff's article
in the New York Times on 1/22/90.

"In testimony last week Mr. Morris said he has long been engaged in
research on computer security.  While he was in high school, he said, he
was hired as a summer intern at Bell Laboratories; that was after he
broke into the computers at the research center.

Mr. Morris said the incident has taught him a lesson.  Since then he
has..."

/------------------------------------+----------------------------------------\
|John "Fast Eddie" McMahon           |    Span: SDCDCL::FASTEDDY (Node 6.9)   |
|Advanced Data Flow Technology Office|Internet: [e-mail] |
|Code 630.4 - Building 28/W255       |  Bitnet: FASTEDDY@DFTBIT               |
|NASA Goddard Space Flight Center    |GSFCmail: JMCMAHON                      |
|Greenbelt, Maryland 20771           |   Phone: [phone] (FTS: 888-2045)  |
+------------------------------------+----------------------------------------+
|X.400 Telenet:(C=USA,ADMD=TELEMAIL,PRMD=GSFC,O=GSFCMAIL,S=MCMAHON,G=JOHN,I=J)|
|GSFC XNS (3+Mail):              {[e-mail]}:INTERNET:GSFC|
+-----------------------------------------------------------------------------+
|"Living a 9600 Baud Lifestyle in a 1200 Baud World" - R.A.J.                 |
\-----------------------------------------------------------------------------/

------------------------------

Date:    Tue, 23 Jan 90 14:40:00 -0500
From:    <[e-mail]>
Subject: Innocent until....

>> I would remind you that he _allegedly_ unleashed the Internet Worm.
>> Innocent before proven otherwise and all that stuff, you know...

> Not so.  It is a finding of fact that he released the worm.  It
> is alleged that that was a criminal act.  He is guilty of
> releasing the worm.  He is innocent of a crime until it is proven
> that the act was criminal.

As of the time of your posting, what judicial process has concluded with a
finding of fact that he released the worm?

John Cofer
[e-mail]

------------------------------

Date:    Tue, 23 Jan 90 20:40:36 +0000
From:    [e-mail] (Brad Morrison)
Subject: Re: Shrink-Wrapped Software

[e-mail] (Bernie Cosell) writes:
>ensys.ensys.com!silvlis.com![e-mail] (Michael S. Maiten) writes:

>}[e-mail] writes:

>}>   Users can protect themselves
>}>   and discourage this risky practice by refusing to deal with retailers
>}>   that offer them the right to return.

That's WEIRD.  Viruses or not, I can't imagine that anyone in their
right mind would really adhere to this sort of practice, much less
advocate it!  "Don't deal with them unless you're stuck with what you
buy" ???  Not a Real World Solution (tm).

>}Stores that offer return policies are exactly the ones with whom I do
>}deal, since it is almost impossible to see if the software will meet
>}my needs by reading the box or trying out the store demonstration
>}copy.

This sounds closer to the pulse of the average consumer.  Not that
retail software companies are consciously trying to rip us off, but I
think that buyers need some avenue of exchange besides writing to the
manufacturer.

>}What they should do is to be more careful when accepting the
>}returned items (check for missing materials, and check for infection
>}of the disks) before returning the person's money.

Yes, they should.  The burden of checking should be on the seller
(retail outlet *or* anyone else in the chain), not the consumer.
Unfortunately, it seems to be one of those cases where the people in
that critical position of software sales clerk are just not
knowledgeable enough on the whole to know how to check, much less how
important it is to check.  What's the difference between a computer
salesman and a used-car salesman?  The used-car salesman *knows* when
he's lying.

>Actually, isn't [checking returned software] almost totally trivial for
>the store --- all they need
>to [do] is, before they re-shrink-wrap, do a sector-by-sector, byte-
>by-byte
>comparsion of the *entire* disk(s) that were returned against a master
>set
>the store keeps.  It doesn't seem hard, and surely cannot take long,
>and [as] far
>as I can tell totally elminates [(sic)] the problems.

Sadly, the only hardware that many major software retailers have on
their premises besides their cash register is a shrink-wrapping machine.
I was in a well-known store the other day, and overheard a salesman tell
a customer, "No, we don't carry that [popular software package].  They
require a system on-site for "live" demonstrations, and we don't keep a
system here."

"What about the demos running in the front of the store?", inquired the
customer.

"Oh, that.  That's just a video."

Okay, so they have a cash register, a shrink-wrapper, and a VCR.  :-)
- --
Brad Morrison                [phone] | My MEATLOAF is RUINED--because
Ferranti International Controls Corporation | my kitchen lacks a FULL STREAMS
[e-mail]                        | IMPLEMENTATION!!!
[e-mail]                  |            -- Zippy the UNIXhead

------------------------------

Date:    23 Jan 90 00:00:00 +0000
From:    "David.M..Chess" <[e-mail]>
Subject: re: Requests/Questions (PC)

[e-mail] (Fridrik Skulason):

> 2) The "Palette" virus has been reported to be 1538 bytes long. Can anybody
>    confirm that ?  The reported identification string matches my copy of
>    "Zero Bug" which has an infective length of 1536 bytes. Either we have
>    two variants or the "1538" may just be an error. Besides - 1536 is a much
>    nicer number - it turns out as 11000000000 in binary.... :-)

The only virus I've heard referred to as "Palette" is the "Zero Bug"
or "1536" virus, which is 1536 (hex 600) bytes long.   I have, for
instance, one text file which begins "Description of the 'Palette
Virus' or 'Zero Bug Virus'" and goes on to describe the 1536.  My
sample of the 1536/Zero-Bug definitely contains a virus 1536 bytes
long.  No evidence of a different virus, two bytes longer, here!
Probably just a typo on someone's part?

DC

------------------------------

Date:    23 Jan 90 15:34:12 +0000
From:    [e-mail] ( Jamie Saker -- Student, UNO)
Subject: Re: WDEF at University of Oregon (Mac)


[e-mail] (Hervey Allen) writes:
> Since people seem to be reporting occurrences of the WDEF virus, hopefully
> to track its spread, I will throw in my two cents worth.

I'll add my two cents worth too.  At the Univ. Nebraska Omaha, on 16 January,
we had an outbreak of WDEF virus on 10 machines (SEs).  After installing
anti WDEF software (all servers also have Disinfectant eliminate infected
disks) the probablem has been eliminated.

So now we only have occasional Scores problems to worry about:)

_____________________________________________________________________________
/     Jamie Saker  Editor-in-Chief   Monitor Month   [e-mail]    \

------------------------------

Date:    23 Jan 90 17:37:11 -0500
From:    Dave Loveless <[e-mail]>
Subject: The STONED Virus (PC)

   We just been hit with the STONED virus. We're not sure how much the virus
has spread and we need to know what the impact of the virus is? We know
the virus has corrupted the boot record but we don't know what it really does?
What does it REALLY do? If you know the answer to these questions - please
send me an E-mail message or if you prefer respond via VIRUS-L.
- -----------------------------------------------------------------------
*********************************
*                               * David W. Loveless
* Today's Question?             * Technical Support Analyst
*                               * The University of Western Ontario
* What is the impact, if your   * Computing and Communications Services
* PC gets "STONED"?             * Administrative Systems Support
*                               * Room #16, Stevenson-Lawson Building
********************************* London, Ontario
E-Mail:                           CANADA N6A 5B8
     [e-mail]         PHONE: [phone]  EXT: 5993

------------------------------

Date:    Tue, 23 Jan 90 23:07:54 -0400
From:    GEORGE SVETLICHNY <[e-mail]>
Subject: Re. Universal virus scans

 Concerning the theoretical proof of the impossibility of a universal
 virus scan, [e-mail] (Kelly Goen) writes (Virus-l V3 Issue
 17):

 ><<deleted>> ... it is possible with memory
 >protection architectures to defend totally(well at least 99% of the
 >time) against intrusion by infectious processes...<<deleted>>
 >
 >..<<implied explicative deleted>>..
 >the remaining 1 % are easily caught by an informed and
 >knowledgable user....<<deleted>>

Thesis:

 There are two interesting points about Vesselin's
 ([e-mail]) program P1 (Virus-L V3 Issue 13). In the first
 place, it's self-referential since it scans itself. This is interesting
 and important (a lot of such impossibility proofs are based on
 self-reference) but not germain at the moment. The other is that its
 effectiveness is due to its *knowing* what the alleged defence is. Well,
 this isn't all that profound either since obviously, knowledge of a
 defence helps you penetrate it (and in the ideal theoretical case it
 actually gets you through), but this is precisely the situation at hand.
 Any virus hacker worth his salt knows what the current defenses are and
 will try to program around them. And it might even be advantageous to
 mimic P1's structure and play dumb if scanned positive hoping for a
 false-alarm verdict and survival to strike elsewhere.

 I would venture to say: 99 % of the time, protected by proper memory
 architecture, 0.9 % of the time easily cought by an informed and
 knowledgable user, and 0.1 % of the time it gits you.

Antithesis:

 Kelly of course has a very valid point. On the practical side, the non
 existence theorem doesn't mean we should give up trying to catch all
 viruses, it just means we should not try for a purely *algorithmic*
 solution. Actually, for any given real machine, a theoretical universal
 virus detector *does* exits. Since the memory is finite there are only a
 finite number of programs, and any finite problem is decidable (just list
 the guilty programs). This of course again is totally useless as a
 practical solution. We are left then with intellegence as our ultimate
 weapon, which is Kelly's point.

Synthesis:

 For certain infinite subclasses of programs (back to the infinite
 memory Turing case) the virus problem could be decidable, and here is a
 legitimate place for scanners. Present-day scanners are probably good
 stabs at resolving these types of subclass problems and a bit more of
 theory could be useful here.

Here and There:

 Clearing the air of the emotional aura surrounding "virus" or the
 scholarly aura sorrounding "halting problem" one sees that (still in the
 Turing case) it's undecidable to say if a program does almost anything
 that one can think of. It's undecidable if a program prints "Whoopie!" on
 the screen, or if it will beep. Just make appropriate and obvious
 modifications to Vesselin's construct. This means that the virus case is
 not really all that special.

 cheers (In russian: "Nice Driveway!")

 ----------------------------------------------------------------------
 George Svetlichny                 |
 Department of Mathematics         | It's impossible to decide if a
 Pontificia Universidade Catolica  | program will flame you.
 Rio de Janeiro, Brasil            |
                                   |
 [e-mail]              |
 ----------------------------------------------------------------------

------------------------------

Date:    Tue, 23 Jan 90 18:19:17 -0800
From:    <[e-mail]>
Subject: Re: Eradicat'Em 1.0. Is is safe?? (Mac)

> I remember, dimly, seeing warnings right after WDEF surfaced about the
> Eradicat'Em Init, mainly that it was unstable.  Now that I have that init
> and am responsible for protecting two public Macs, I can't find those
> articles, of course.  So, with apologies for bringing it up again, is
> Eradicat'Em 1.0 a safe, stable, and effective way to combat WDEF?  Please
> e-mail versus cluttering the board with old news.  Thank you much in
> advance.

You're probably remembering John Norstad's posting of, and subsequent
warning note about version 1.0 of the Eradicator! INIT.  Eradicator!
1.0 was indeed unstable, and should not be used... it can cause
crashes.

Eradicator! has been updated several times;  the current version (as
far as I'm aware) is 1.52.  I haven't used any version more recent than
1.2.  The release-notes for 1.52 indicate that a number of problems
have been fixed, but that the authors aren't planning continued
support now that commercial anti-viral programs are capable of coping
with the WDEF virus.

Eradicat'Em is based in part on Eradicator!, but its "innards" were
almost completely reworked.  It patches an entirely different set of
traps, and avoids certain techniques which got Eradicator! into
trouble.  For all practical purposes, it's an entirely different INIT.

Eradicat'Em 1.0 is quite stable.  It has been tested on everything from
a Mac 512ke (System 4.2) up through the Mac IIci and Mac Portable
(System 6.0.4).  It was even tested, successfully, on an Atari running
a Spectre Mac-emulator package.  John Norstad's tests indicate that
it's entirely effective at identifying and removing WDEF on his
machines.

The only problem-report I've seen concerning Eradicat'Em 1.0 involves
a three-way interaction between Eradicat'Em 1.0, the Virtual INIT,
and the INIT-loader for "The Debugger".  If all three of these INITs
are installed, the machine crashes at boot time;  remove any one, and
everything's fine.  Gatekeeper is also affected... it's not compatible
with the Virtual/Debugger combination.  We don't know why.

Aside from this one rather exotic incompatibility, I believe that
Eradicat'Em is both safe and reliable.  I run a LOT of INITs (a full
screen-strip and then some, on an AppleColor monitor), and I haven't
encountered any problems on my machines.

Disclaimer:  I'm biased, as I wrote Eradicat'Em.

- --
Dave Platt                                             VOICE: [phone]
  UUCP: ...!{ames,apple,uunet}!coherent!dplatt   DOMAIN: [e-mail]
  INTERNET:       coherent![e-mail],  [e-mail]
  USNAIL: Coherent Thought Inc.  3350 West Bayshore #205  Palo Alto CA 94303

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Thursday, 25 Jan 1990    Volume 3 : Issue 21

Today's Topics:

Re: universal virus scanners.
The near-universal virus scanner
Re: WDEF at University of Oregon (Mac)
Virus vs. worm
The Yankee Virus (PC)
Re: the Internet Worm trial
Morris found guilty (one more time!)
There is more than one virus called AIDS !!!
Internet Worm Trial
Re: Shrink Wrap...still safe?
Disinfectant 1.4 (Mac)
Question on CLEAN55 and Jerusalem B (PC)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

---------------------------------------------------------------------------

Date:    Wed, 24 Jan 90 02:11:26 -0400
From:    GEORGE SVETLICHNY <[e-mail]>
Subject: Re: universal virus scanners.

 In Virus-L v3 issue 19, [e-mail] writes

> On 17 Jan 90 15:07:00 +0700, [e-mail] wrote:
>  "Construct the program Q thus:
>    program Q; begin
>    if is_a_virus(Q) then (* do nothing *) else infect_other_programs;
>    end.
>
><<deleted>>
>
> What will probably happen will be that program Q or R will # examine
> itself by going through all its code, including the instruction to
> examine itself - repeat from # forever. ...<<deleted>>....

  There is no infinite regress here since roughly speaking program Q (R is
  similar) calls upon an *external* algorithm to scan itself and does not
  call upon *itself* to scan itself. By *assumption*, is_a_virus is a
  *decision algorithm* and so its call with *any* argument (including Q)
  terminates. The whole point is to show that no such guaranteed-to-
  terminate procedure exists. Thus there can be no reentrant call to Q
  within the is_a_virus call and so no problem. These programs *are*
  self-referential but the self-reference is not of the paradoxical type as
  in "I'm a liar." One can convince oneself that there is no problem by
  actually *writing* self-referential programs in the style of Q and seeing
  that they work. Let print_whoopie be a boolean function that opens a
  binary file and determines if the ascii string "Whoopie!" is present
  there or not as a sequence of bytes. Write the program W as sketched:

   program W;begin
    if print_whoopie("W.COM") exit else print("Whoopie!);
   end.

   function boolean print_whoopie(string file_name);
    begin
     {Put the print_whoopie code here.}
    end


  Implement this in C, Pascal, LISP, BASIC, whatever. It can be done, it
  works, there's no infinite regress and W foils the alleged (and admitedly
  very naive) "Whoopie!"-printing decision algorithm (which also doesn't
  exist). (print_whoopie will say W.COM will print it but W.COM actually
  does not.) The scan of W.COM by W.COM does not enter a loop just as the
  existent self-scanning virus scanners do not.

  It's probably true that there is a universal virus scaner is_a_virus with
  the property the if P *is* a virus then is_a_virus(P) will stop and
  identify it as a virus but if P is *not* a virus, is_a_virus(P) will
  either say so or never stop. Presumably is_a_virus would do this by
  running a copy of P in a remote part of the infinite Turing tape with
  copies of other programs for P to infect, a series of exhaustive and
  systematic "test drives" of P. Of what use this result would be, even if
  true, I don't know. For the halting problem one can write an immediate,
  trivial and useless "stop scanner" of this sort:

         program will_stop (P);
         begin
          run(P);
          print("This program stops.");
         end.

  The vulgar analog of this for the virus case is: "If it got you it's a
  virus, if it hasn't yet it may not be." but one should be able to do
  better than this.

 ----------------------------------------------------------------------
 George Svetlichny                 |
 Department of Mathematics         |
 Pontificia Universidade Catolica  |           Whoopie!
 Rio de Janeiro, Brasil            |
                                   |
 [e-mail]              |
 ----------------------------------------------------------------------

P.S. I post-scribe therefore I am.

------------------------------

Date:    24 Jan 90 03:19:19 +0000
From:    kddlab!csl.sony.co.jp![e-mail] (Rik Smoody)
Subject: The near-universal virus scanner

[e-mail] (Dr. A. Wood) writes:
> "Construct the program Q thus:
>   program Q; begin
>   if is_a_virus(Q) then (* do nothing *) else infect_other_programs;
>   end.
> . . .
>A very simple argument and very powerful.".
>
>These are versions of the ancient paradox which comes in various forms:-
>(1) Statement (1) is untrue.
>(2) Jack said "Everything I say is a lie.".
>(3) The set of all (sets which are not members of themselves): is it a member
>    of itself?
>
>What will probably happen will be that program Q or R will # examine
>itself by going through all its code, including the instruction to
>examine itself - repeat from # forever. Probably both Q and R will get
>into infinite recursion when used to examine themselves, but may well
The examples remind me a lot of a card with the following printed
on each side:
    "Do you know how to keep a moron busy for hours?  Answer on reverse"

I suppose if I have agreed, irrevocably, to play the logic game with
the virus (or signed the pact with the devil), I am stuck in an infinite
loop with a single processor and no reset button.
But much more realistically, I use the following heuristic:
If I suspect that some program contains a virus, I do not install it
without carefully checking the suspicions.
Now I can write the near-universal virus scanner as follows:
        If you see anything suspicious, tell me about it.
In refining "suspicious", I would put "infect_other_programs" as a
very suspicious activity.  Even asking about "infect_other_programs"
can be considered suspicious, so yes, my virus checker would report
that it engages in some suspicious behaviour.

        This person walks into a bar near CIA headquarters and asks the
        people around if they know any spies.  The CIA collapses in
        swirls of confusion as everyone tries to deduce if the first
        person happens to be a spy???

Maybe the trap is assuming that we have to be fair with computer programs.
But they do not have "rights".  So what if I refuse to install a program
which really would not harm me?  All I lose is the use of that program.
- --
Rik Fischer Smoody
Sony Computer Science Lab, Inc.,  3-14-13 Higashigotanda
Shinagawa-ku, Tokyo 141 Japan
[phone]

------------------------------

Date:    22 Jan 90 19:37:36 +0000
From:    tatem@smu!ti-csl!m2.ti.com (Joe Tatem)
Subject: Re: WDEF at University of Oregon (Mac)


Could someone please send me a description of DEF and its symptoms? We
are experiencing 'interesting' behavior and so far I only know about
NVIR and Scores.

                                        Joe Tatem
                                        [e-mail]

 ---- This .signature intentionally left blank ----

------------------------------

Date:    24 Jan 90 01:53:34 +0000
From:    hp-sdd!hplred.HP.COM![e-mail] (Jeff Perry)
Subject: Virus vs. worm


   This is probably a simple question, but I haven't heard it asked (or
answered). What is the difference between a virus and a worm?

Inquiring minds want to know,
Jeff Perry

------------------------------

Date:    24 Jan 90 11:14:00 +0700
From:    [e-mail]
Subject: The Yankee Virus (PC)

        Due to the several requests for information about the
Bulgarian viruses, I shall give their description here.  However I
shall post the descriptions one by one because (1) I need time to
write the message in English and (2) I would like to keep the message
relatively short.  If I overlook something in the descriptions, feel
free to send me your questions.  When they accumulate I shall send
additional info.

        I have already sent these descriptions to Prof.  Harold Joseph
Highland --- the editor in chief of the journal "Computers &
Security".  However I have sent them trough the regular mail (I had no
access to the e-mail system at that time), so maybe he still does not
have them.  By the way, does anybody know the e-mail address of H.J.
Highland?

                           The Yankee Virus
                           ----------------

        In fact, I'm a bit guilty for the creation of this virus.  At
that good old time (about 18 months ago), there was only one virus in
Bulgaria.  This was the VHP-648 (Vienna) virus.  Since it infects only
.COM-files, I thought that infecting an .EXE-file is much more
difficult.  And I was fool enough to express my thought publicly.
The challenge was taken immediately and the virus was created in less
than a month.

        It infects .EXE-files only since the infection method for the
.COM- ones was very well known and therefore was not interesting to
bother with.  Files of any length can be infected.  However, if the
program CodeView (a debugger which comes with the Microsoft
programming languages) gets infected, it does not work any more.  I
cannot figure out the reason for this.

        The virus is not memory-resident.  It activates only when an
infected program is run.  When activated, it searches the whole
directory tree on the current drive for a still non-infected .EXE-file
and infects it.  (The directory tree is searched in a depth-first
method.  This means that first all the subdirectories are searched and
then the current directory is searched.) On each run of an infected
program one more .EXE-file of the file system gets infected.  Then the
virus plays the "Yankee Doodle" melody and starts the original
program.  It has no other effect.

        Please note, that this virus is not the one, known in the
Western countries as the "Yankee Doodle virus".  The later infects
both .COM- and .EXE-files, is memory-resident, and plays the melody
*only* at 5 pm.  The Yankee virus is not memory-resident, infects only
.EXE-files and plays the melody *every time* when an infected file is
run.

        The infected files are recognized by the virus by the string
"motherfucker" (excuse me) which appears at the very end of the file.
Note that the string is in lower case only.

        The author of the virus did not spread the virus itself.  In
fact he did even worse --- he spread its source code.  Now there is at
least one mutation of the virus.  It does not play the melody and is a
little bit shorter.  There were rumors about another mutation which is
able to format the hard disk, but they are still not confirmed.

        This virus is not very widely spread in our country.  The main
reason should be that it infects only the files on the current drive
- --- i.e.  is not very "virulent".

        I wrote a program which can recognize the two known versions
of the virus and is able to cure the infected files.

                                        Vesselin



------------------------------

Date:    24 Jan 90 14:16:08 +0000
From:    Irving Chidsey <[e-mail]>
Subject: Re: the Internet Worm trial

EASTRA@morekypr writes:
<interesting how all the computer experts on this list are legal
<experts as well since the posters to the list have already convicted
<the defendent, they would clearly be ideal jurors after all, guilty
<until proven innocent is clearly the attitude here
<
<- -- ray easton

        Don't confuse factualy guilty with legaly guilty.  If a criminal could
convince every potential juror that he was in fact guilty before the jury was
chosen then the prosecution would be stymied because there would be no unbiasse
d
people available to serve.  There have been several cases recently where this
was a possibility because of pretrial publicity.
        It is even possible for a jury to believe that the accused is guilty
but still declare them innocent because the guilt was not proven "beyond a
reasonable doubt".  I recently served on a jury which decided two counts
that way.

                                                Irv

I do not have signature authority.  I am not authorized to sign anything.
I am not authorized to commit the BRL, the DOA, the DOD, or the US Government
to anything, not even by implication.
                        Irving L. Chidsey  <[e-mail]>

------------------------------

Date:    24 Jan 90 08:25:00 -0700
From:    "AMSP9::CHRISTEVT" <[e-mail]>
Subject: Morris found guilty (one more time!)

      The 23 Jan 90 Dayton Daily News printed an AP article about the Internet
Worm case...to go along with all the others out there...Here are some
excerpts...

      SYRACUSE, NY -

      "Robert T. Morris, 24, faces up to five years in prison and a $250,000
fine. He is the first person brought to trial under a 1986 federal computer
fraud and abuse law that makes it a felony to break into a federal computer
network and prevent authorized use of the system.

      "[Monday night] The jury returned its verdict about 9:30 p.m. after
nearly six hours of deliberation.

      "`Morris may not have intended his worm program to paralyze a nationwide
computer network in 1988, but it was no accident that the worm attacked the
network,' U.S. Justice Department trial lawyer Mark Rasch said in closing
statements earlier in the day.

      "`The worm didn't break in by accident or mistake. Robert Morris
intended for the worm to break in,' he said.

      "Defense attorney Thomas Guidoboni argued that [Morris] made a
programming error that caused the worm to go berserk and disable the Internet
system.

      "`It's not the side effects, it's not the mistakes, but what he actually
intended to do,' Guidoboni said. `He never intended to prevent authorized
access.'

      "Prosecutor Ellen Meltzer reminded the jury in her summation that
testimony showed Morris deliberately stole computer passwords from hundreds of
people so the worm could break into as many computers as possible.

      "She added that Morris took deliberate and conscious steps to make the
rogue program difficult to detect and eradicate...

      "Ms. Meltzer said at least six earlier versions of the worm were found
on Morris' Cornell computer accounts and that his own comments on the worm
program used the words `break-in' and `steal.'

      "Guidoboni insisted that Morris didn't intend to cause permanent damage
to computer files.

      "`Morris took steps to limit the worm's growth,' Guidoboni said.

      "`If he intended to bring the systems down, he didn't need to control
the growth. He could have just let this thing go,' he said."


                                   ET B ME
                                     VIC
                                      !

Disclaimer: The preceding bits of randomness are the product of a mindwarp and
            do not necessarily represent the views of anyone other than me...
            SO THERE!!!

Victor ET Christensen                    "The Club is the Sign of Vengeance;
[e-mail]                It holds no man as friend.
[e-mail]            The Spade is the Sword of Justice;
[e-mail]   It's rapier marks the end."
                                               ~ Sword of Justice

------------------------------

Date:    Wed, 24 Jan 90 12:27:12 +0000
From:    "Dr. A. Wood" <[e-mail]>
Subject: There is more than one virus called AIDS !!!

To clear up possible confusion, I feel that I should remind readers
that there is more than one sort of computer virus (and similar)
called AIDS:-

(1) The AIDS computer virus. I read somewhere that it was written in C.
(2) The notorious AIDS trojan diskette which was distributed from Panama.

The connection between (2) and other definitions of AIDS is that (2),
when run, pretends to be a survey questionnaire about the biological
AIDS virus.  {A.Appleyard} (email: [e-mail]), Wed, 24 Jan
90 12:17:36 GMT

------------------------------

Date:    Wed, 24 Jan 90 23:43:00 -0500
From:    [e-mail]
Subject: Internet Worm Trial

>As of the time of your posting, what judicial process has
>concluded with a finding of fact that he released the worm?

I wondered whether or not anyone would challenge that
assertion.

As of the time of my posting, The New York Times had already reported
Morris had so testified.

As of the time of the original assertion to which I responded, there
had been such a finding by formal proceedings at Cornell University.

At the time of the original assertion, Morris had already testified,
but it had not yet been reported in the times.  The assertion was
posted in Australia where the poster would be expected to have limited
access to the US media.

However, the question of whether or not Morris had released the worm
or not had never been in dispute.  The only questions in dispute were
intent and criminality.

While prudently silent since his initial panic, Morris never denied
releasing the worm nor was it denied on his behalf.  Intent to do harm
was denied on his behalf by friends and attorneys.  In the trial he
denied intent to do harm, but never intent to intrude.  The code
itself was prima facia evidence of intent to intrude.  I read no
reports of any attempts to refute that evidence.  From the reports and
the verdict, I conclude that that was sufficient for a finding of
guilty.

William Hugh Murray, Fellow, Information System Security, Ernst & Young
2000 National City Center Cleveland, Ohio 44114
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840

------------------------------

Date:    Thu, 25 Jan 90 05:45:33 +0000
From:    craig@apple!tolerant.com (Craig Harmer)
Subject: Re: Shrink Wrap...still safe?

bnr-vpa!bnr-fos!bmers58![e-mail] (Mark Lord) writes:

>Hmm.. the simple solution to most of these problems is to distribute
>software on diskettes without write-enable slots (ie. built-in write
>protection tabs).  There is simply NO way, short of modifying hardware,
>for such diskettes to become virus infected on the customers premises.

it's trivial to tweak a 5.25 inch floppy disk drive so that it thinks
the diskette is writable.  in the case of a drive i did this on (by accident!),
it required only a simple mechanical adjustment (that was an old
Shugart SA400 as modified by Apple for an Apple II).  i suspect that
drives of more recent manufacture would require (trivial) electrical
modification.

now if they shipped the disk in a tin can (like tylenol) ...

>I'm actually quite suprised that 99% of the software I purchase comes
>*without* write protection tabs installed on the diskettes (5.25" floppies).
>I really have to force myself to install that critical tab *before* inserting
>the disk in *any* drive.  This guarantees that I don't infect the masters.

good point.  it also helps prevent accidents.

>| Mark S. Lord                           | Hey, It's only MY opinion. |
>| ..!utgpu!bnr-vpa!bnr-fos!mlord%bmers58 | Feel free to have your own.|

{apple,amdahl}!tolsoft!craig                            [e-mail]
[phone] (h)                                      [phone] x220 (w)
        [views expressed above shouldn't be taken as Tolerants' views,
                or your views or my views.  they exist a priori.]

------------------------------

Date:    Thu, 25 Jan 90 09:45:28 +0000
From:    "Dr. A. Wood" <[e-mail]>
Subject: Disinfectant 1.4 (Mac)

In the VIRUS-L newsletter was this:-
........................................
Date:    Sun, 10 Dec 89 00:10:16 -0500
From:    [e-mail]
Subject: Disinfectant 1.4 (Mac)

"Disinfectant  1.4  is a new   release of  our   free  Macintosh virus
detection and   repair  utility. Version  1.4  detects    and  repairs
infections by the new  WDEF virus (see below). In  version 1.4  we  no
longer refer to  the various  clones of the nVIR B  virus by name.  We
refer to them simply as generic "clones of nVIR  B." All references to
the  individual clone names have been   removed from both the document
and the reports generated by the program. We feel that the creators of
these clones do  not deserve the  publicity they receive when they see
the names they  have  chosen  in print,  especially since some  of the
names are offensive."

I appreciate what the author of Disinfectant feels about the notoriety
and the offensiveness; but I appeal to him to put Disinfectant back to
printing  the clone names. Knowing what  clone is  in each outbreak of
nVIR  B,   is very  helpful in   tracing   origins   and  channels  of
transmission of nVIR B infections. For example, if establishment X had
an attack  of  nVIR  B  clone  "Plague" and   no  others,   and later,
establishment Y had an attack of nVIR B clone "Smallpox" and no others
(if there were  clones with these  names), then Y probably  didn't get
infected from X. This very helpful clue  wouldn't be available, if the
sufferers  couldn't find which strains of  nVIR B are involved in each
infection.

{A.Appleyard} (email:  [e-mail]), Thu, 25 Jan 90 09:41:28 GMT

------------------------------

Date:    Thu, 25 Jan 90 09:22:00 -0500
From:    "Paul D. Shan [phone]" <[e-mail]>
Subject: Question on CLEAN55 and Jerusalem B (PC)

I recently obtained a copy of CLEAN55, and VALIDATE.  My first contact
with any virus in the IBM world happens to be the Jerusalem B virus.
The documents with CLEAN55 say that the Jerusalem viruses may not be
successfully removed from all EXE files.  I ran CLEAN against an
infected copy of a program, and then did a VALIDATE on it and on a
known good copy of the same program.  The file sizes matched, but the
Checksums did not match.

Could someone explain to me exactly what the Jerusalem virus does to
replicate, and what it does to damage files?  Also, could someone
explain to me why the Jerusalem virus may not be successfully removed
from some EXE files?

While I'm on the subject, is there a library somewhere that contains
technical information on these viruses, such as how EVERY known virus
replicates, what it infects, and EXACTLY what gets damaged?  I have
the VIRUS CHARACTERISTICS list which is a GREAT quick reference, but
it says that, for example, the virus "affects system run-time
operation."  EXACTLY how does it affect operation?


Thank you for your help!


Paul Shan

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Thursday, 25 Jan 1990    Volume 3 : Issue 22

Today's Topics:

Re: Internet worm writer to go to trial Jan 16th. (Internet)
Re: Universal virus detection
Disinfectant versions (Mac)
STONED virus in LRS lab at Univ. of Guelph (PC)
"Desktop Fractal Design System Not Infected"
Submission for comp-virus
Jerusalem Virus (PC)!
Trial & Double Standard
Signature Programs
Signature Programs
Signature Programs
Practical a-priori viruscan?
Signature Programs

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

---------------------------------------------------------------------------

Date:    25 Jan 90 15:23:08 +0000
From:    [e-mail] (Gene Spafford)
Subject: Re: Internet worm writer to go to trial Jan 16th. (Internet)

[e-mail] (Gordon D. Wishon) writes:
>Gene, in your report (_The Internet Worm Program:  An Analysis_), you
>speculated that the code may have been written by more than one
>person.  Has anything come out in the trial to support this?

To my knowledge, nothing came out in the trial about this.
I do know, however, that the password cracking code in the Worm was
not written by Mr. Morris.  He obtained that code when he spent a
summer at Bell Labs.  It was part of a security testing package
written by other people, and it appears that he made a copy he had
access to.

I also suspect that he got the code to break "fingerd" from someone
else, but he would have to comment on that.

- --
Gene Spafford
NSF/Purdue/U of Florida  Software Engineering Research Center,
Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-2004
Internet:  [e-mail]   uucp:   ...!{decwrl,gatech,ucbvax}!purdue!spaf

------------------------------

Date:    25 Jan 90 08:21:50 +0000
From:    [e-mail] (jc van Winkel)
Subject: Re: Universal virus detection

There are a few points I think that should be made. Let's (for the
sake of argument) assume that the undecidability proof is valid. This
only implies that a virus detector will not be able to 1) catch all
viruses or 2) 'find' a virus in an uninfected program. It does not say
anything about percentages, just that it MAY happen that a wrong
conclusion is drawn. All current viruses can be detected by either
appearance or by behavior. For all current viruses: Once you know its
structure, you can detect it.

(Take a look at the biological analogy: We can detect almost all
biological viruses that are known, but it is IMPOSSIBLE to detect
viruses that have not yet emerged. If a new virus was synthesized,
either by mutation (which happens all the time), or by man (I don't
like the thought) we would only be able to detect it if it shared some
characteristics with known viruses. If the virus is too new, we can
only conclude that someone has cought a desease that is unknown to
man.

Now for my second point: It is also indecidable for a virus to see
whether or not a program is a virus detector. The informal proof runs
along the same path as the informal virus detection proof. In the
virus detection proof, use is made of the fact that the virus 'knows'
that a program is a detector. Yet, this is indecidable, so not all
hope is lost...

There are many more proofs of indecidability, Prof Cohen mentioned
them in his Thesis. They are:

Detection of viruses by appearance.
Detection of viruses by behavior.
Detection of evolution of a known virus.
Detection of viruses by appearance.
Detection of triggering mechanisms by appearance.
Detection of triggering mechanisms by behavior.
Detection of evolution of a known triggering mechanism .
Detection of virus detectors by appearance.
Detection of virus detectors by behavior.
Detection of evolution of a known virus detectors.

Although this theoretical discussion is interesting, I think that with
some measures we can get pretty safe computing! Using a decent file
access control mechanism and not letting anyone write to a file that
is executable, but reserving that right to programs with 'compiler' or
'linker' status will make viruses very hard to write.

These are my own ideas, not necessarily my employer's

------------------------------

Date:    Thu, 25 Jan 90 09:47:00 -0600
From:    "David D. Grisham" <[e-mail]>
Subject: Disinfectant versions (Mac)

This was cross posted to: Newsgroups: comp.sys.mac
Subject: Re: Disinfectant 1.6
Summary: No version 1.6
References: <[e-mail]> <[e-mail]>
Followup-To: Jeff Wiseman's note

This is probably a typo.  However, there is _NO_ version 1.6
of Disinfectant!  If you have one let me or John Norstad know
immediately.
dave
_In art <[e-mail]> [e-mail] (Jeff Wiseman) writes:
_>In article <[e-mail]> [e-mail] writes:
_>>   I have enjoyed using Disinfectant in it's earlier versions but
_>>since downloading version 1.6 [including WDEF virus protection], it
                     ^^^^^^^^^^^^^
                     NO Such Version!

_>>refuses to pass ANY of my files.  Any suggestions?  Thanks.
_>Quarantine your Mac??
_>(Sorry Bob, I suppose it isn't funny but I couldn't resist :-)
_>--
_>Jeff Wiseman: ....uunet!tellab5!wiseman OR [e-mail]

------------------------------

Date:    Thu, 25 Jan 90 14:01:34 -0500
From:    Peter Jaspers-Fayer <[e-mail]>
Subject: STONED virus in LRS lab at Univ. of Guelph (PC)

We have the Stoned virus here (trademark msg "Your PC is now stoned!"
upon boot).  It has appeared in one lab only (so far).  Novell.  They
boot from floppy (strange, I thought "stoned" infected partition
sectors of hard disks, so why msgs upon floppy boot?), and McAfee's
SCAN flags the floppies as being infected in the boot sector. OK, so
I'm wrong.

  Anyhow:

1> Effects of this virus (how dangerous?)?
2> Complete documentation on this virus is available from?
3> Disinfectors available? (pls not SIMTEL, I can never get on SIMTEL20)
4> Helllpp!

/PJ                                                 [e-mail]
                     -------------------------------
If you try to please everyone, somebody is not going to like it.

------------------------------

Date:    Thu, 25 Jan 90 10:44:09 -0500
From:    Eric Roskos <[e-mail]>
Subject: "Desktop Fractal Design System Not Infected"

This is a follow-up to my 1/12/90 posting in which I observed that I
had bought and used a copy of the Desktop Fractal Design System
allegedly infected with the "1813" virus, but had not seen any
problems.

I have since looked more closely at my executables, which are said to
increase in size as a result of this virus, and have also run the
virus-scan program from SIMTEL20 on the original disk.

My executables do not increase in size, and the original disk does not
show the presence of any virus when checked with this program.  I also
have not seen any abnormal behavior such as was described as being
caused by this virus, while using the system for very heavy software
development during this month.

>From the evidence presented on VIRUS-L to date, it appears that of a
sample size of two, one copy was infected, and one was not.  It would
appear that a larger sample would be helpful in order to understand this
problem.

- --
Eric Roskos ([e-mail] or [e-mail])

------------------------------

Date:    25 Jan 90 20:41:41 +0000
From:    [e-mail] (Mike McCann),
         [e-mail] (Mike McCann)
Subject: Submission for comp-virus WDEF at Clemson University

For those of you who have an interest in these things...
  The WDEF Mac virus has reached Clemson University (after UNC Chapel
Hill, where else could it go?).  GateKeeper Aid is working fine for
all those people who chose to take my advise and install it.

Happy virus hunting,
- --
Mike McCann       [phone]   Internet = [e-mail]
Poole Computer Center (Box P-21)     Bitnet = [e-mail]
Clemson University
Clemson, S.C. 29634-2803         DISCLAIMER = I speak only for myself.

------------------------------

Date:    Thu, 25 Jan 90 15:59:00 -0400
From:    Michael Greve <[e-mail]>
Subject: Jerusalem Virus (PC)!

     We recently discovered the Jerusalem A virus attached to a program
    on a office machine.  I have a couple questions.  1. What does this
    virus do and how does it infect? and 2. How does one go about getting
    rid of the virus.  We have Viruscan, which is how we detected the virus,
    but we have no way of getting rid of PC viruses.  This is our first PC
    virus.   I guess we're in the big time now!!!!

                                        Michael Greve
                                        University of Pa.
                                        Wharton Computing
                                        [e-mail]

------------------------------

Date:    25 Jan 90 11:27:10 -0500
From:    Bob Bosen <[e-mail]>
Subject: Trial & Double Standard

Now that a jury has determined that Robert Morris Jr. was guilty
of a crime when he wrote and unleashed the famous "Internet
Virus", it is time to consider the implications of the punishment
that society will exact from him. It's also time to examine
society's motives in inflicting and publicizing such punishment.
Obviously, if punishing young Morris can deter others from
attempting similar nefarious activities, society can derive some
benefit. There are those who advocate severe and widely
publicized penalties. On the other hand, there are others who
suggest that a medal of commendation may be more appropriate. It
is unusual to hear such wide-ranging controversy regarding
appropriate punishment after a trial. May I suggest some reasons
for the controversy?

I postulate that the computer world has been attempting to cheat
on the rest of society.  For thousands of years, human society
(in the form of business, banking, and government) has developed
a clear notion of generally accepted practices that defines
prudent management and handling of responsibility. These
standards evolved out of necessity: no single person or
organization can bear the cost of protecting himself from crime
by himself. Trying to anticipate all the kinds of crimes and
trying to get ironclad protection mechanisms into place
beforehand has proven impossible. Therefore, instead of
attempting "perfect" security systems, society has said "We will
share this burden with you if you will follow generally accepted
practices."  Our judicial system and our civil law enforcement
agencies are the result. But these agencies cannot function and
should not protect those who do not accept their portion of the
responsibility. This means abiding by the law and meeting the
requirements of generally accepted practice.

Long before computers and computer crime, businesses learned that
they could not afford to fully protect themselves from their own
employees. It is simply impossible to hire enough guards, to buy
enough alarms, or to build enough walls. Instead, for thousands
of years, business has relied upon the practice of "auditing".
Individual Accountability has become the generally accepted means
by which banks, businesses, and governments have carried out
their responsibilities to themselves, to each other, and to
society.

I postulate that use of a computer does not grant license to
disregard thousands of years of generally accepted practice. But
it is clear that the computing community has attempted to live
outside this norm for the past 30 years.  The Internet virus is
but the most recent spectacular event to illustrate how far
outside the mainstream of business practice our integrated
computer systems have been built.

If young Morris had believed he would be held accountable for his
actions, he probably would not have attempted his crime. But
a key fact revealed in the Morris case proves that the controls
that Cornell University thought were in place to "secure" their
computers could not be relied upon to hold users accountable for
their actions. Computer records controlled by Morris contained
the user names and passwords used by hundreds of other users.
Whoever obtained these could have successfully masqueraded under
any of the corresponding identities.  This lets all users of
Cornell systems off the hook. This is best illustrated by the
following example:

   Suppose you are a graduate student of computer science at
   Cornell. You would never think of committing a computer crime,
   and have never done so.  You are careful with your handling of
   your passwords, and you change them every month without
   exception. One day, you are summoned to the office of campus
   security, and upon your arrival you notice that the head of Data
   Processing is present, as well as the university's attorney. They
   inform you that several irregularities have been occuring on the
   computer systems you use, and that your user name and password
   have appeared in audits directly associated with these events.
   Perhaps criminal activities have taken place. Your academic
   standing, career, and good name are at stake. You have perhaps 5
   minutes to persuade these people of your innocence or you may
   find yourself in court.

   What do you say? You could proceed along these lines:

   "I didn't do these things. I know I didn't do these things, and
   if you'll think for a minute about the computers and networks you
   force me to use and the way my password traverses them, you'll
   see that there is no way you can hold me accountable for these
   problems. The personal computers I use are not mine, and are not
   under my control. The PC maintenance people and DOS gurus that
   frequent this campus could easily have trapped my passwords at
   any of several levels where they must traverse equipment and
   software that is under THEIR control, not mine. It's YOUR Local
   Area Network, not mine. It's YOUR minicomputers, YOUR data
   communication controllers, YOUR multiplexers, YOUR Wide Area
   Netoworks, YOUR UNIX gurus, YOUR VTAM people, YOUR MVS experts,
   and YOUR programmers who determine what happens to my password. I
   am given no opportunity to protect my password once it leaves my
   fingertips. Robert Morris was able to collect hundreds of
   passwords from users all around this campus, and this proves that
   the problems you are attempting to pin on me could have been
   caused by any of hundreds of different people. You can't pin this
   on me!" And of course, you'd be right.

The problem is that memorized passwords can not be relied upon to
hold users accountable for their actions in todays's environment
of Integrated Systems. There are too many places in our
networked, integrated environment where insiders are routinely
exposed to passwords. Indeed, it is not unusual for tens of
thousands of copies of passwords to be made, retained, and
broadcast during each month of routine use. I am NOT saying that
a large proportion of these exposures are actually exploited. I
AM saying that the mere PROBABILITY of password exposure
eliminates the POSSIBILITY of user ACCOUNTABILITY. Why is this
situation tolerated in the computing community when equivalent
situations are considered criminally negligent in the practices
of the rest of society?

Why don't bankers abandon the use of credit cards, photo IDs and
signatures and just debit our bank accounts whenever a merchant
tells them our passwords? It would be a lot easier. Imagine
getting a letter from your bank along these lines:

   Dear esteemed depositor:

   As you know, for the past 15 years, you have been entrusted with
   our bank card, and have used it in your banking transactions. We
   are replacing your bank card with a password. You will no longer
   have to carry your bank card. Your new password is "FRED". Please
   keep it secret. Whenever you want to withdraw funds or make
   credit card purchases, just write FRED at the bottom of the
   invoice and we'll take care of the rest. If you ever suspect
   that anybody has found out your password, please drop drop us a
   post card with "FRED" crossed out in red pen and a new password
   of your choice written in blue ink. It is your responsibility to
   keep your password secret. You will be held accountable for any
   and all banking transactions that say FRED on them, including
   questionable or illegal transactions, for which you will be
   prosecuted to the full extent of the law.

Computer professionals: does this sound painfully familiar? Why
does this sound so silly in a banking or business context when it
is so universally accepted if a computer is involved? Who is
responsible for the perpetration of this double standard? Is it
possible that the punishment of Robert Morris helps us all feel a
little safer from the accusation that a large portion of the
blame should rest with us?

Bob Bosen
Enigma Logic

------------------------------

Date:    25 Jan 90 11:23:16 -0500
From:    Bob Bosen <[e-mail]>
Subject: Signature Programs

When I began this in-depth series of discussions on authentication
algorithms and signature programs late last year, I was alarmed and
frustrated by the lack of attention being paid to the subject of well-
researched "standard" authentication algorithms.

At this point I must say I am gratified by the response. We've heard from
Ralph Merkle, Bill Murray, Jim Bidzos, Ross Greenberg, Y. Radai and
others directly, and we've heard indirectly from Fred Cohen, Robert
Jueneman, and Prof. Rabin. Obviously there are a lot of divergent
interests and opinions represented here, but among all the disagreement I
see emergent patterns that I consider very healthy. First, it is clear
that the preponderance of expert opinion now favors increased use of
algorithms that are more sophisticated than what I called "some
programmer's guess" at an authentication algorithm. Second, it is clear
that there are ways of "leveraging" the performance of these
sophisticated authentication algorithms. As I pointed out in my original
posting and as Jim Bidzos has further stressed, slow performance need not
be a problem because it is not always necessary to apply the slower
algorithms directly to the entire file in order to obtain a sophisticated
signature: It is possible to combine two or more well-understood
algorithms in order to obtain the advantages of each and the detriments
of neither. Third, it is clear that the use of sophisticated algorithms
allows functions and features, such as those suggested by Bill Murray
(use of a MAC to ensure that programs are received as they were shipped)
that would otherwise be impractical or untrustworthy.

Thanks to all that have supported the need for using sophisticated
authentication algorithms!

- -Bob Bosen-
Enigma Logic Inc.

------------------------------

Date:    25 Jan 90 11:24:23 -0500
From:    Bob Bosen <[e-mail]>
Subject: Signature Programs

In his posting of Jan 4 '90, Y. Radai acknowledges that the added
sophistication of X9.9 compared to CRC may be well worth the added time
in the case of authentication of bank transfers or other conventional
applications, and then asks me if I have ever considered the possibility
that this sophistication might be wasted when dealing with viruses. Yes.
Of course I have considered this possiblity. I considered it long and
hard. I was forced to reach the same conclusion that bankers and
businessmen reached when they insisted that sophisticated means be
developed to protect their business transactions: Not all programs are
video games. Some programs are important. Some programs, if attacked by a
malicious virus or trojan horse, could pervert banking transactions or
business balances.  Some programs, if attacked, could place human lives at
risk. We are not just talking about reformatting and restoring a hard disk
here. I am convinced that businesses and governments need protection that
is capable of resisting the attacks of a sophisticated insider who
specifically targets high-value operations.

Furthermore, I would like to postulate that the day may come when
somebody in the anti-virus community will produce a really good defense
mechanism that is practical, reliable, sensibly priced, and really worthy
of widespread market acceptance. Perhaps two or three such excellent
programs will emerge and distinguish themselves as the clear leaders.
Each such program could eventually be installed on millions, or even tens
of millions, of future computers. Let's hope it happens some day. And
let's hope no virus writer is able to target one such market leader and
forge signatures!  Obviously in such a situation with millions of users,
a protection mechanism would make a tempting target for skilled virus
writers or trojan horse writers. In such a situation, it is entirely
possible that criminals might NOT launch a widespread attack designed to
spread to a large population. (That would reveal their skill and deprive
them of the opportunity to profit from it.) They might instead confine
the spread of their virus to a very specific population of familiar
computers known to control great value.

For these and other reasons, I must disagree with the opinions that Y.
Radai enumerated in his posting and upon which he based his latest set of
conclusions. Specifically, in his opinion (1), Mr. Radai says that a
virus must perform all its work ... "on the computer which it's attacking
and in a very short time". That is not necessarily true. In networked
environments with shared file systems, (and especially if remote
execution is available), viruses could execute on different computers and
take as much time as they needed. Also, as pointed out by Bill Murray,
viral infections during the process of software distribution may be done
off-line at the convenience of the attackers. And it is not necessary for
a virus to SUCCEED in performing all its work in a single very short
attempt. A virus might divide its clandestine attempts into very small
chunks that are attempted frequently enough to guarantee eventual
success, but which do not result in any pollution of off-line storage
unless defense mechanisms (presumably marginally sophisticated ones of
the type Mr. Radai hopes will be sufficient) are successfully bypassed.

I must also disagree with Mr. Radai's opinion (2), wherein he posits "By
its very nature, a virus is designed to attack a large percentage of the
users of a particular system." Why? What's to prevent a virus writer from
launching a "surgical strike" against a small population of familiar
computers that are known to control assets or information of great value?
Once again, I think Mr. Radai's view of the world does not reflect the
realities of business or criminal nature. To be sure, most of the viruses
we've seen so far have behaved like little PAC-MAN games, gobbling up
everything in sight. But how long will it be before this video-arcade
mentality is outgrown?

As to Mr. Radai's opinion (3), he says that "a virus writer is not in a
position to know what checksum algorithms may be in use on the computers
on which his virus is unleashed." That's true TODAY. In fact, TODAY, it's
even worse than that. Most virus writers can safely assume that there is
NO protection of any kind on the target computers. But if our society is
ever going to overcome its current vulnerability, we'll need reliable,
low-cost defense mechanisms that are worthy of widespread use. This
implies a necessity for economies of scale. Therefore, this opinion (3)
will not necessarily be true for very long. Let's HOPE that when we get
to that point, the authentication algorithms used are more sophisticated
than simple checksums!

- -Bob Bosen-
Enigma Logic

------------------------------

Date:    25 Jan 90 11:24:38 -0500
From:    Bob Bosen <[e-mail]>
Subject: Signature Programs

Although I disagree with the opinions expressed at the beginning of Mr.
Radai's posting of Jan. 4, 1990, I find his analysis of the trade-offs
between algorithmic sophistication and performance useful. From what I've
read in this forum of late, it does appear that Ross Greenberg and Y.
Radai are at one end of this spectrum and that Bill Murray, Ralph Merkle,
Jim Bidzos, Fred Cohen, and the others mentioned in Mr. Radai's Jan. 4
posting are more or less at the other end with me. (If I've
misrepresented your views here, gentlemen, I hope you'll forgive and
correct me for it. I'm reading between the lines.)


- -Bob Bosen-
Enigma Logic


------------------------------

Date:    Thu, 25 Jan 90 16:47:50 -0400
From:    GEORGE SVETLICHNY <[e-mail]>
Subject: Practical a-priori viruscan?

 In Virus-L v3 issue20, [e-mail] (Russell McFatter) writes:
 >...<deleted>
 >
 >All things considered, we can actually write a program that, given
 >a questionable bit of code, can give one of the following results:
 >
 >OK:  this program is safe and will not infect other applications.
 >BAD:  the target program could, under some unknown circumstances,
 >      modify other applications.
 >INCONCLUSIVE:  The target program either modifies executable code or
 >     executes variable data.
 >
 ><deleted>...

The problem of viruses (or more generally, nasties) is mostly program
semantics (what programs do) and human intent and only secondarily
program syntax (how programs are written).  Syntactic problems are
decidable, semantic problems generally are not (in Turing machines, in
finite-state machines they generally are but the decision procedures
are very rarely practical). What Russel suggests is that there is a
useful practical approximate syntactic solution to the semantic and
intentional problem of nasties. I seriously doubt this.

Up to now nasties have been a bit flamboyant and show-offish. Their
more subdued versions would be identical to normal bugs. The same code
in a spreadsheet program that causes it to erroneously recalculate
every now and then is either a bug if the programmer did not intend it
or a nasty if it was put in on purpose. Surely the "O.K." category
doesn't mean "bug free" (wouldn't it be wonderful otherwise?). To be
100% OK the category can only include those programs that can be
proved to be correct on the object-code level and this means
practically no program at all.

The third category is grossly underestimated. One need not write to
the code segment or execute from the data segment to create a nasty
that doesn't fall in the second category. There are serious dangers
within the processor instruction set. Consider an unconditional jump
to an address given by a register or memory content, extremely useful
in dealing with jump tables. Now, from the purely syntactic point of
view you can't tell where you are jumping to. You can jump to a nasty
piece of code. This can be in a portion of the program that
syntactically is identified as being constant data: message strings,
global program constants, etc.. It can also be in a piece of
syntactically identified and innocuous-looking code *displaced* by a
byte or two. Clarifying: Suppose one has somewhere in the code a
conditional jump, a "jmp nz" instruction. The syntactic analyzer looks
down both branches and finds nothing suspicious. Now the z branch is
dummy since the programmer made sure this condition never holds
(semantics). The dummy branch looks innocuous to the syntactic
analyzer but the same byte sequence *starting from the second byte* is
a nasty piece of business. One enters this nasty code by a "jmp reg"
instruction in some other part of the program.  Wolf semantics in
sheep sytax. Very well, you say, let's put "jmp reg" instructions on
the suspect list, however the "jmp reg" instuction is equivalent to
"push reg" followed by "ret". Hence all code that uses "push" and
"ret" is suspect, and this includes practically all the useful
software under the sun. What all this means is that an a-priori scan
for nasties *has* to be smart enough to anlyze the consequences of
"jmp reg" instuctions and their kin, to see that stack discipline is
maintained, to analyze what gets pushed and poped and when this can
become a code adress, etc. A lot of semantics to approximate by
syntax.

There is a biological analog to the "second byte" situation above.
Some genes overlap with others, that is, a base-pair sequence
ABC.DEF.G...  codes for one protein (a triple of base pairs is a codon
for an amino acid) while the *same* but phase-shifted sequence
BCD.EFG.H.... codes for another protein and both are actually produced
by the organism. It's rather remarkable that such "gene multiplexing"
can produce two useful proteins. In machine language code one doesn't
see such code multiplexing since it must be practically impossible to
multiplex two useful code sequences this way, but one can easily
multiplex "silly" with "nasty" code and use the silly to camouflage
the nasty. (Detecting silliness is another semantic problem.)

The "O.K." category is thus practically empty, the virus hackers will
make sure that their creations don't fall in the "BAD" category by
carefull programming, and the "INCONCLUSIVE" category must be enlarged
to include nasty "semantically-driven" jumps and code-multiplexing as
a possibility which makes it contain practically all useful programs.
This is hardly a practical solution.

The upshot of this is that unless one changes to radically diferent
memory and processor architectures (hard-wired separation of code and
data memory, rigid code boundaries, fixed-instruction-length
processors, separate stack for "call" and "ret", explicit jump-table
handling ... ) there is not much hope for an effective a-priori
scanner for nasties. One will have to be content with a-posteriori
scanners for known nasties and watchdog programs that report on
suspicious activity (semantics) rather than try to detect suspicious
structure (syntax). Beyond this there are of course the people
problems that have to be dealt with by education, law, politics,
psychology, etc.

 ----------------------------------------------------------------------
 George Svetlichny                 |  Multiplexed sentences:
 Department of Mathematics         |
 Pontificia Universidade Catolica  |  What sort of feet are moldy?
 Rio de Janeiro, Brasil            |   Hats or tofee? Tar 'em, oldy!
                                   |
 [e-mail]              |
 ----------------------------------------------------------------------

------------------------------

Date:    25 Jan 90 15:14:57 -0500
From:    Bob Bosen <[e-mail]>
Subject: Signature Programs

In reading Ross Greenburg's recent comments on Signature Programs, and in
trying to respond to his specific statements for me, it appears that he
must have missed my original posting in which I explained ways by which
it is possible to extract excellent performance from authentication means
based on combinations of ANSI X9.9, ISO 8731-2, and conventional CRC
techniques.  (Jim Bidzos has recently described a similar technique which
includes RSA authentication.) For the benefit of others who might have
also missed that background, I'll repeat a brief summary here.

It is possible to greatly leverage the performance of sophisticated
authentication algorithms by carefully controlling certain factors. Among
them are:

1- The PERCENTAGE of the file that is subjected to the sophisticated
algorithm. This can sometimes be quite a small fraction of the whole
file.  (The remainder of the file can be processed by an industry-
standard CRC algorithm. There are various techniques deriving from
cryptology that can be used to cause the effects of the sophisticated
algorithms to "ripple through" all the way to the final signature.)
Properly implemented, these techniques can result in a reliable,
virtually unforgeable signature that is calculated almost as quickly as a
conventional CRC.

2- WHEN the signature is calculated. Obviously you can infuriate your
users if you make them stand around twiddling their thumbs while all your
files are authenticated in batch mode during the bootstrap process. On
the other hand, if most authentication is done "on the fly" as programs
are loaded, users hardly notice the delays.

3- How OFTEN the signatures are calculated. It really isn't necessary to
recalculate each and every signature every day, or even every time a
program is executed. Sensible authentication frequencies will depend on
the work environment, presence of known threats, and the value of assets
controlled, but may average once or twice a month in typical business
environments.

4- The ALGORITHM chosen. Although its strength is not as well researched
as DES, ISO 8731-2 has withstood at least some respectable public
scrutiny, and runs at least ten times as fast as DES. Early indications
are that SNEFRU is a very strong algorithm that is much faster than DES.
RSA is much slower than DES. (And as I've consistently said since my
earliest posting, CRCs of varying strengths are available and can be used
in appropriate combinations with some of the more sophisticated algorithms
to speed things up still further.)

By judiciously balancing these variables, it is possible to create a
fast, reliable, sophisticated system that performs so quickly that users
hardly notice it. I have to agree with Ross Greenberg that a
sophisticated algorithm that performs poorly won't get used at all, and
is therefore worse than an unsophisticated algorithm. But I also know,
from direct, first-hand experience, that we need not limit ourselves to
thinking of sophisticated algorithms as being slow performers. All things
considered, there is really no reason NOT to abandon the simplistic
algorithms in favor of those that are likely to be beyond compromise by
virus writers for several years to come.

- -Bob Bosen-
Enigma Logic

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Monday, 29 Jan 1990    Volume 3 : Issue 23

Today's Topics:

Re: Internet Worm
RE: Virus request
Another WDEF infection (Mac)
Re: WDEF at University of Oregon (Mac)
WDEF A infection (Mac)
Re: Trial & Double Standard
Re: theoretical virus scanning
New virus? (Mac)
Virus Modeling
Virus Info Request (PC)
W13 Polish text (PC)
WDEF in public places (Mac)
Re: Practical a-priori viruscan?

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

---------------------------------------------------------------------------

Date:    Wed, 24 Jan 90 18:29:14 +0000
From:    [e-mail] (Geoffrey H. Cooper)
Subject: Re: Internet Worm

I agree, Morris acted irresponsibly.  He did something he knew was
wrong and thought to be a minor annoyance to the world; then it blew
up in his face.  That is certainly puts his actions within the realm
of criminal activity, in the same way as someone who deliberately runs
a red light and accidentally hurts someone.

One thing that makes me wonder: A newspaper article claims that Morris
wanted to stop the worm when it started to get out of control, and
decided that he wasn't able to.  When the Internet group started to
try and control it, why didn't he offer to help?  At least a copy of
the source code would have been of great assistance.  Instead, he
hides and waits for the FBI to find him.

Would not this have been his best opportunity to show his benign
intentions?  Or perhaps he was advised not to help by someone.

Did anyone hear anything about this from the trial?

- - Geof
- --
[e-mail] / aurora![e-mail] / [e-mail]

------------------------------

Date:    Thu, 25 Jan 90 12:08:35 -0500
From:    woodb!scsmo1![e-mail]
Subject: RE: Virus request

> >From:  IN%"[e-mail]"  "Vax discussion" 21-JAN-1990 23:11:59.77
> >Subj:  <Vax 85> Virus on VAX
> >From: [e-mail]
>
> >        Hi!
>
> >        Dose anyone have a idea about VAX Virus? Or interesting on
> >        it? I think the most difficult point is how to spread it
> >        out. So if someone has any bright idea, contact with me.
>
> >                                                James Huang
>
>         Here is a message from UMNews's Vax discussion list.  I
> thought the list should know about this.  The node is Taiwanese.

This is insane.  Obviously this particular Taiwanese knows little
about VAX networking and uses of viruses(worms) in those networking
facilities.

He will probably get a few replies as well as some sources. What as a
whole can the computer industry do to help prevent individuals like
this from the potential releasing of these viruses(viri?) into the
vast networks??

Should it be illegal to own or transmit virus source (for non-security
personnel)??

Also, should there be an international watchdog agency set up to
investigate such requests??  Should the CIA/FBI/FCC be involved in
cooperation with IBM/DEC/AT&T/etc.. to form a task force along with
our list's virus expert?

Has anyone contacted this person's administration along with MAINE's
and BITNIC/BITNET administration?

Right now, its up to us to report these requests and its the
responsibility of MAINE to act on requests submitted via UMNEWS.

Can we make it illegal to have virus sources without stomping on our
constitutional rights??  What about other countries??

- --
 DON INGLI-United States Department of Agriculture - Soil Conservation Service
 INTERNET: scsmo1![e-mail]    PHONEnet: 314!875!5344
 UUCP(short): uunet!scsmo1!don        UUCP(long): uunet!mimsy!woodb!scsmo1!don
              These are my opinions. I represent myself.
 Who do you think you are, Bjorn Nitmo(sp)?  David Letterman '90 Catch Phrase

------------------------------

Date:    Thu, 25 Jan 90 14:30:35 +0000
From:    [e-mail]
Subject: Another WDEF infection (Mac)

Just for the record, since I haven't seen any other report of it here,
Cambridge public user area Macintoshes were hit with WDEF A on or
about 22 January.  Disinfectant 1.5 was recommended to deal with it.

Douglas de Lacey <[e-mail]>

------------------------------

Date:    23 Jan 90 15:34:12 +0000
From:    [e-mail] ( Jamie Saker -- Student, UNO)
Subject: Re: WDEF at University of Oregon (Mac)

[e-mail] (Hervey Allen) writes:
> Since people seem to be reporting occurrences of the WDEF virus, hopefully
> to track its spread, I will throw in my two cents worth.

I'll add my two cents worth too.  At the Univ. Nebraska Omaha, on 16 January,
we had an outbreak of WDEF virus on 10 machines (SEs).  After installing
anti WDEF software (all servers also have Disinfectant eliminate infected
disks) the probablem has been eliminated.

So now we only have occasional Scores problems to worry about:)
_____________________________________________________________________________
/     Jamie Saker  Editor-in-Chief   Monitor Month   [e-mail]    \

------------------------------

Date:    Thu, 25 Jan 90 16:26:46 +0700
From:    Chuck Martin <[e-mail]>
Subject: WDEF A infection (Mac)

So that it can be tracked, I'm reporting that our office Mac was
infected by WDEF A.  Disinfectant 1.5 removed it and we have
implemented tighter security.  I don't know if any of the other Macs
on campus are infected.

-
 -------------------------------------------------------------------------------
                           Chuck Martin, Consultant
            Computer Information Center, Washington State University
       MARTINCH @ WSUVM1.BITNET                      [phone]
-
 -------------------------------------------------------------------------------
             Beam me up Scotty.  There's no intelligent life here.
-
 -------------------------------------------------------------------------------

------------------------------

Date:    26 Jan 90 01:33:04 +0000
From:    Bernie Cosell <[e-mail]>
Subject: Re: Trial & Double Standard

[e-mail] (Bob Bosen) writes:

}Why don't bankers abandon the use of credit cards, photo IDs and
}signatures and just debit our bank accounts whenever a merchant
}tells them our passwords? It would be a lot easier.

For good or ill, we already have done just that.  The entire
phone-in-credit-purchase industry is built around _precisely_ that
functionality.  And even on in-person sales, the dial-in authentication
codes have nothing to do with any actual 'identification' [although
they do require the shopkeeper to actually have your card [or a
facsimile!] in his hand].

Similarly, with ATM cards, the primary 'line of defense' is some
security-by-obscurity encoding on the card and a three-digit password
[which, I think, is also encoded on the card].

Banks do not verify signatures on checks that they honor.  The only
line of defense here is the individual patron verifying his own checks
when they come in at the end of the month.  If you think the bank's
have people actually comparing signatures on the zillions of checks
that come in, you're wrong.

This is not to excuse the almost-total lack of true security [and audit
trails and such] in most of our computer systems, BUT.... it just isn't
as much of a "double standard" as you paint it to be.

And this is pretty funny:

}   Dear esteemed depositor:

}   As you know, for the past 15 years, you have been entrusted with
}   our bank card, and have used it in your banking transactions. We
}   are replacing your bank card with a password. You will no longer
}   have to carry your bank card. Your new password is "FRED". Please
}   keep it secret. Whenever you want to withdraw funds or make
}   credit card purchases, just write FRED at the bottom of the
}   invoice and we'll take care of the rest. If you ever suspect
}   that anybody has found out your password, please drop drop us a
}   post card with "FRED" crossed out in red pen and a new password
}   of your choice written in blue ink. It is your responsibility to
}   keep your password secret. You will be held accountable for any
}   and all banking transactions that say FRED on them, including
}   questionable or illegal transactions, for which you will be
}   prosecuted to the full extent of the law.

That is almost exactly what my bank said when I got my ATM card and I
had to select a "PIN" [except for the bit at the end about liability
for misuse of my card].  Is your bank different?

  /Bernie\

------------------------------

Date:    Thu, 25 Jan 90 16:22:14 +0000
From:    [e-mail] (Peter da Silva)
Subject: Re: theoretical virus scanning

The fact that the halting problem is not applicable to FSMs isn't relevant,
because it's not known that part of the system involved is a FSM. The person
operating the computer is part of the system.

For example, if you run your virus in the halting machine and discover it
in an infinite loop polling the keyboard you'll decide it's not going to
infect the machine (halt). Actually it's waiting on a keystroke.
- --
 _--_|\  Peter da Silva. [phone]. <[e-mail]>.
/      \
\_.--._/ Xenix Support -- it's not just a job, it's an adventure!
      v  "Have you hugged your wolf today?" `-_-'

------------------------------

Date:    26 Jan 90 13:28:33 +0000
From:    [e-mail] (Mike McCann)
Subject: New virus? (Mac)

Posted for someone else:

We've had a report in our department (MatSci) of a new n-vir-like
virus.  The latest version of Virex is able to detect it, but cannot
identify it, nor can it repair infected applications.  Disinfectant
1.5 does not find it.

Upon examining several infected applications with ResEdit, they all
have a spurious resource "fuck".  Has anyone encountered this strain
before?  If so, how can we repair infected files, and configure other
virus-detecting programs to recognize it?

D. Daniel Sternbergh
[e-mail]

Mike McCann       [phone]   Internet = [e-mail]
Poole Computer Center (Box P-21)     Bitnet = [e-mail]
Clemson University
Clemson, S.C. 29634-2803         DISCLAIMER = I speak only for myself.

------------------------------

Date:    Fri, 26 Jan 90 08:31:00 -0500
From:    [e-mail]
Subject: Virus Modeling

A co-worker of mine wrote:
     One way to characterize a Trojan Horse or a virus is to build
     mathematical, abstract models of them.  Such a model may be an
     n-tuple of interrelated subjects, objects, and operations.
     Thereafter, abstracted audit data and host machine
     characteristics can be organized to find if all the components of
     such an n-tuple are present.

My assignment was to help with the research in attempting to come up
with such a model.  Now, from what I have been reading on the Virus
forum, I am wondering if this task is even possible.

A proof was offered that stated that it was not possible to come up
with an algorithm that could find all viruses.  Then, this proof was
refuted based on the fact that a computer is a finite state machine.
Based on this, it was also stated that a theoretical universal virus
dectector does exist for every real machine, however making one would
not be practical.

One theoretical universal virus detector would be to compare the state
of the computer against a list of what is and what is not a virus.  This
is a task too large to attempt.  However, if someone were to be able to
come up with the distinguishing characteristics of a virus, what sets
it apart from other programs, how humans can tell when they look at a
program if it is a virus or not, then maybe an algorithm could be
developed.  One that could catch viruses by comparing the state of the
computer against the model, and the characteristics of a virus.

Is it possible to come up with such a model?  Is it possible to list
ALL of the characteristics of a virus?  If so, what might these
characteristics be?  If not, why not?

David T. Opitz  - NSCS

------------------------------

Date:    Fri, 26 Jan 90 12:30:20 +0000
From:    Dr. P. R. Fielden <[e-mail]>
Subject: Virus Info Request (PC)

Our dept. has just been hit by the STONED virus and I've found PING
PONG and PING PONG B on a local public access cluster on the same
floor as our dept so I suppose I'll be finding them soon.  I've been
asked to produce a document about viruses for all staff and students,
I'm sure somebody must of already of done this. I would appreciate it
if anybody that has would send me a copy.  Also what is the best way
to protect a public access cluster.

The following ideas have been put forward.
1. Install SCANRES and keep everybody informed.
2. Buy diskless computers.
3. Manually disconnect the floppy drive cable.
4. Install either software or hardware security system.
5. Try something like Flushot.
6. Do nothing - it'll go away !! <- Not my suggestion.
  Any comments please.

Reply to the list or to [e-mail] (Janet) - the domain is
reversed for the rest of the world.

Thanks in advance, Andy Packham.
  Peter Fielden  ([e-mail])

------------------------------

Date:    Fri, 26 Jan 90 09:02:00 -0500
From:    [e-mail]
Subject: W13 Polish text (PC)

The translation of the Polish text in the W13 virus is: "The COM type
program does absolutely nothing.  It is designed to be a decoy for the
virus."

I know it was requested that it be sent to the requestor, not to the
network, but unless it is posted on the network, there will be
duplication of effort.

On another matter, there is a simple procedure which can be used to
check for most viruses and other forms of corrupt code.  It is this:
All viruses have to be in some executable file in order to act.  Usually
insertion of a virus either changes an existing executable file or
creates a new one.  The new executable file may be apparent or hidden,
and if hidden may be a hidden file per se or may disguise itself as a
bad sector.  Therefore a simple program which compares the size of all
executable files with a known good standard, and then compares the size
of hidden files and bad sectors with a known good standard, will check
for most viruses.  Even if it is hidden in the idle space of an
executable file, thus not changing its size - and this is rare - it will
be detected as soon as it propagates to any other executable file.  If
anyone is interested, I will post a sample program which does this and
also allows for updates as new known executable files are put on line.
The program can be placed in the autoexec.bat or hello type bootstrap
files for automatic execution whenever the machine is turned on or
invoked at any time.  In the bootstrap file it adds about 35 seconds to
boot time to the average system.  Of course it is possible to design
viruses to get around this, but it adds more work to the attacker, at
little cost to the defender.

One final note:  All of the 45 books I have read on computer security
that have said anything about viruses claim that you have to delete
everything once your system is infected.  Not so.  Text files cannot
propagate a virus and should not be deleted unless they have already
been trashed by the corrupt code.  Nor is there any need to delete
executable files which have not been corrupted, although they are
generally easier to replace since most people's executable files
represent commercial software while their text files represent custom
made files.

DGStewart NCSC

------------------------------

Date:    26 Jan 90 16:56:37 +0000
From:    [e-mail] (carl radens)
Subject: WDEF in public places (Mac)

One aspect of the computer virus discussion which bears consideration
is the "public health" policy question. Commercial and public Mac and
IBMPC services such as laser printing stations and other graphics
services are potential infection sources; they may also be subject to
government regulation and legal action.

In this location, we've twice found the WDEF on disks used at a popular
national copy center chain which also offers MAC laser printing services.
We found the WDEF at a university bookstore MAC store back at the
beginning of December.

These are places where a large volume of disks pass each day, and where
(presumedly) professional services are rendered on a retail commercial
basis.

What is the professional responsibility in cases where a customer informs
the merchant of a viral infection, and the merchant does not remedy
the situation on their own machine ?

The WDEF virus appears to be benign; no data was lost and Gatekeeper Aid
removed the infection in each case. The Nationally known copy center
was informed of the problem, and several weeks later a WDEF infection
was again obtained from their machine. This time no damage was inflicted.
Its only a matter of time before a more serious virus appears, and I
wonder if these commercial places are just going to be sitting on their cans
when it happens.

Is there any legal precedent for this type of situation ?

- -Carl Radens, Cincinnati
[e-mail]

------------------------------

Date:    Fri, 26 Jan 90 13:05:44 -0500
From:    Peter Jones <[e-mail]>
Subject: Re: Practical a-priori viruscan?

>From:    GEORGE SVETLICHNY <[e-mail]>
>Subject: Practical a-priori viruscan?
>
>There is a biological analog to the "second byte" situation above.
>Some genes overlap with others, that is, a base-pair sequence

I'm reminded of a few LP records with more than one groove on them, that
will play one of several programs, depending on where the needle happens
to land. Monty Python, among others, has porduced such a record.

Peter Jones     MAINT@UQAM     (514)-987-3542
"Life's too short to try and fill up every minute of it" :-)

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Monday, 29 Jan 1990    Volume 3 : Issue 24

Today's Topics:

Re: Shrink-Wrapped Software
Re: "Desktop Fractal Design System Not Infected"
Re: Internet worm writer stands trial (Internet)
Re: Signature Programs
More re: Desktop Fractal Design System
Re: Signature Programs
Re: Signature Programs
STONED Virus data (PC)
WDEF Virus in California (Mac)
More about UVDs
Three new viruses (PC)
The V651 virus (PC)
Re: Virus vs. worm

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

---------------------------------------------------------------------------

Date:    26 Jan 90 21:00:24 +0000
From:    [e-mail] (Mark Draughn)
Subject: Re: Shrink-Wrapped Software

[e-mail] (Bernie Cosell) writes:
>ensys.ensys.com!silvlis.com![e-mail] (Michael S. Maiten) writes:
>
>}[e-mail] writes:
>
>}>   Users can protect themselves
>}>   and discourage this risky practice by refusing to deal with retailers
>}>   that offer them the right to return.
>
>}Stores that offer return policies are exactly the ones with whom I do
>}deal, since it is almost impossible to see if the software will meet
>}my needs by reading the box or trying out the store demonstration
>}copy.  What they should do is to be more careful when accepting the
>}returned items (check for missing materials, and check for infection
>}of the disks) before returning the person's money.
>
>Actually, isn't this almost totally trivial for the store --- all they need
>to is, before they re-shrink-wrap, do a sector-by-sector, byte-by-byte
>comparsion of the *entire* disk(s) that were returned against a master set
>the store keeps.  It doesn't seem hard, and surely cannot take long, and far
>as I can tell totally elminates the problems.

This requires the stores to keep safe copies set aside for every piece
of software they sell.  It's a lot of work and it costs a lot in terms
of time and equipment.

How about this instead:  Software vendors could ship the media separate
from everything else in the piece of software, including the license
to the software.

When someone buys a piece of software from the store, they get the entire
package and the disks.  (Having separate media also makes it easy to choose
5.25" v.s. 3.5" etc.)  If the customer returns the software, the store keeps
everything except the actual disks.  The disks are returned to the vendor.
The vendor then sends the store a new set of disks.  The store still has
the same number of legal, licensed copies, so nothing much has changed.

This seems like a good idea because the vendor already has the equipment,
expertise, legal permissions, and master copies needed to produce virus-free
copies of the software.

The cost of doing this is small--just the cost of making and shipping a few
disks.  Whether the cost should be carried by the vendor, the store, or the
customer is a detail that market forces will probably control.  My guess is
that the retail stores will end up eating the cost as part of the cost
of good customer service.

There are problems with cheating--the retailer could re-wrap, or the vendor
could simply re-ship returned software--but I don't think this will make
things worse.  The retailer has relatively little to gain by cheating when
he can get good copies so cheaply.  The PR damage from even a single incident
of shipping infected software should keep the vendor from cheating.

How does that sound?

- --
EMAIL: [e-mail]+--------------+ Academic Computing Center
BITNET: SYSMARK@IITVAX       | Mark Draughn | 10 W. 31st St.
VOICE: [phone]       +--------------+ Illinois Institute of Technology
ALSO: ...{nucsrl|att}!iitmax!draughn          Chicago, Illinois  60616

------------------------------

Date:    Fri, 26 Jan 90 14:50:52 -0500
From:    Eric Roskos <[e-mail]>
Subject: Re: "Desktop Fractal Design System Not Infected"

Since writing the posting in today's VIRUS-L with the above Subject line,
I have received some seemingly rather hostile mail criticizing the above
statement.

I would urge people who object to the above statement to (a) reread the
original posting, (b) note the quotation marks around the statement, and
(c) reread past issues of VIRUS-L regarding this problem more closely.

My point in writing that particular Subject line was, and is, that to
date there is no evidence *which has been presented on VIRUS-L* that the
Desktop Fractal Design System, as shipped from the publisher, is
infected.  There is only the claim that it is, and the statement
(secondhand) that the publisher is "aware" of the problem.  Whether they
are aware that some people say the program is infected, or whether they
have copies of it from their stock that are infected, is not known from
this statement.

On the other hand, we do have evidence -- I have it right here -- that
at least one copy is *not* infected, as purchased from a local bookstore
(Reiter's Scientific Bookstore in Washington, DC).  This also is not
evidence that the copy was not infected when shipped -- someone might
have bought the copy, disinfected it, and returned it to the store, for
example -- but the converse possibility is true for the allegedly
infected copies.  Since I write-protected the disk before I used it the
first time, I know it has not been written upon since I unwrapped it.

It would be helpful to those of us who have to deal with these issues to
know more about details of alleged virus infections, things such as:

        - Did you personally open and install the infected disk?

        - Did you write-protect the disk before doing so?

        - How many copies do you have that you know to be infected?

        - What is the version number of the software?  Is there any other
          date or serial number information involved?

More facts and less rumors would be helpful, both in understanding the
problem, and ensuring that it is properly identified, particularly when
a virus report contains some highly specific information (such as stating
that a particular item of software is infected).

(Incidentally, I would add here that it would also be beneficial to
software publishers if they would publish their software on floppy disks
without write enable notches in them.  IBM used to do this with their
early PC software disks; I don't recall seeing any like this in a long
time.  It would protect the publishers from being falsely accused of
spreading a virus when in fact the disk was infected by the user during
installation; although it would also eliminate their ability to claim
the latter if they were, indeed, responsible for the infection.  All
around, the practice would seem to be an improvement.)

Disclaimer:  I have no connection with the author or publisher of the
Desktop Fractal Design System; I simply own an uninfected copy of it.

------------------------------

Date:    26 Jan 90 13:38:02 +0000
From:    [e-mail] (Woodrow Baker)
Subject: Re: Internet worm writer to go to trial Jan 16th. (Internet)

> >Gene, in your report (_The Internet Worm Program:  An Analysis_), you

Where or how can I get a copy of this report?

Cheers
Woody

[Ed. It is available via anonymous FTP from cs.purdue.edu in
/pub/reports.  I also keep a copy of it on the CERT anonymous FTP,
cert.sei.cmu.edu, in /pub/virus-l/docs.]

------------------------------

Date:    26 Jan 90 13:53:51 +0000
From:    [e-mail] (Woodrow Baker)
Subject: Re: Signature Programs

Where can a description of ISO 8731-2 be obtained at little or no cost?

Cheers
Woody

------------------------------

Date:    Fri, 26 Jan 90 18:51:35 -0500
From:    Eric Roskos <[e-mail]>
Subject: More re: Desktop Fractal Design System

In keeping with my own suggestion, I checked the version number on the
copy of this software that is not infected; it is version 1.0, as
labeled on the disk (near the bottom of the green label on the disk),
and when started up it also displays 1.0 as the version number.  Can
someone who has an infected copy post the version number involved? If
it is a different version, that will give some insight.  Thanks...
- --E.R.

PS - This copy I have was purchased about the 2nd week in December.
There is not any other date or serial number marking present, other than
a serial number for the floppy disk itself, "46892C", stamped on the
back in ink.

------------------------------

Date:    Fri, 27 Jan 90 00:28:39 +0000
From:    utoday![e-mail] (Ross M. Greenberg)
Subject: Re: Signature Programs

 [e-mail] (Bob Bosen) writes:
>
>
>1- The PERCENTAGE of the file that is subjected to the sophisticated
>algorithm. This can sometimes be quite a small fraction of the whole
>file.  (The remainder of the file can be processed by an industry-
>standard CRC algorithm. There are various techniques deriving from
>cryptology that can be used to cause the effects of the sophisticated
>algorithms to "ripple through" all the way to the final signature.)
>Properly implemented, these techniques can result in a reliable,
>virtually unforgeable signature that is calculated almost as quickly as a
>conventional CRC.

True, only if you're looking for a known pattern.  Otherwise, you're
guessing that your algorithm is smarter than the bad guys.  Not on my
machine you don't!  You're gonna have to scan the whole file, every
byte to tell me if there has been a change. It's incredible what a
simple one byte change may produce:  changing an INT25 to an INT26 (or
vice versa) makes for a difference that can destroy your hard disk. A
one byte difference.

>
>2- WHEN the signature is calculated. Obviously you can infuriate your
>users if you make them stand around twiddling their thumbs while all your
>files are authenticated in batch mode during the bootstrap process. On
>the other hand, if most authentication is done "on the fly" as programs
>are loaded, users hardly notice the delays.

Assume that your user has a mongo file, maybe .5Meg of code s/he wants
to load up.  For the reasons cited above, you have to do *something* with
each byte of the code.  Take an XT, clocking at 4.77MHz.  Add algorithm
for *each* byte.  Stir slowly.  In the case of the XT, very slowly.  Now,
start adding to the complexity of the algorithm.  Notice the chair in
front of the terminal suddenly gone empty?  That's because the user got
frustrated at the time cost of a very sophisticated algorithm.

>
>3- How OFTEN the signatures are calculated. It really isn't necessary to
>recalculate each and every signature every day, or even every time a
>program is executed. Sensible authentication frequencies will depend on
>the work environment, presence of known threats, and the value of assets
>controlled, but may average once or twice a month in typical business
>environments.

Every time the file is loaded.  Unless you'll guarantee the user, in writing,
that there is no chance the next time I run a program on a supposedly clean
system that I'm not running a damaging program.  Of course, if you'll
guarantee me that the system the user is on is clean and you'll also
guarantee me that the user has introduced *no* new program whatsoever
onto their system, well, maybe I can see your point.  Would you be willing
to guarantee this type of thing?

>
>4- The ALGORITHM chosen. Although its strength is not as well researched
>as DES, ISO 8731-2 has withstood at least some respectable public
>scrutiny, and runs at least ten times as fast as DES. Early indications
>are that SNEFRU is a very strong algorithm that is much faster than DES.
>RSA is much slower than DES. (And as I've consistently said since my
>earliest posting, CRCs of varying strengths are available and can be used
>in appropriate combinations with some of the more sophisticated algorithms
>to speed things up still further.)

Any two simple routines will outfunction a singular more complex routine.
A well known routine, no matter the nomenclature, is easily breakable by
anyone who a) understand the algorithm and b) has a dis-asm program handy.
Two differing methods, say a simply  checksum and a simple bit-add-rotate
will do the trick faster and be just as effective.
>
>By judiciously balancing these variables, it is possible to create a
>fast, reliable, sophisticated system that performs so quickly that users
>hardly notice it.

Interesting claim, but I've not seen usable proof yet -- usable to the real
world, that is.  I agree that complex algorithms will produce complex
results that are difficult to get around -- but so what?

> I have to agree with Ross Greenberg that a
>sophisticated algorithm that performs poorly won't get used at all, and
>is therefore worse than an unsophisticated algorithm. But I also know,
>from direct, first-hand experience, that we need not limit ourselves to
>thinking of sophisticated algorithms as being slow performers. All things
>considered, there is really no reason NOT to abandon the simplistic
>algorithms in favor of those that are likely to be beyond compromise by
>virus writers for several years to come.

I'd be interested in two things, both of which are (I think) easily available.
One:  timing results on real live files with anyone of the more sophisticated
routines you propose versus sime CRC and checksum, and Two: any proof at all
that one is going to prove more difficult than the other for a determined
bad guy with a debugger and the ability to do "MOV DS:[BX], OPCODE_FOR_NOP"
when they feel like it.

Ross M. Greenberg, Technology Editor, UNIX Today!   [e-mail]
             594 Third Avenue, New York, New York, 10016
 Voice:(212)-889-6431 BIX: greenber  MCI: greenber   CIS: 72461,3212
  To subscribe, send mail to [e-mail] with "Subject: Request"

------------------------------

Date:    Fri, 27 Jan 90 00:36:46 +0000
From:    utoday![e-mail] (Ross M. Greenberg)
Subject: Re: Signature Programs

[e-mail] (Bob Bosen) writes:
>When I began this in-depth series of discussions on authentication
>algorithms and signature programs late last year, I was alarmed and
>frustrated by the lack of attention being paid to the subject of well-
>researched "standard" authentication algorithms.

Bob continues, indicating that a bunch of people seem to agree with his
premise that sophisticated algorithms are inherently superior than the
less sophisticated ones.  As one of the named parties, allow me to
disagree, in part:  for authentication that need be done only once, let
the routine be as sophisticated as the data being authenticated need be.
For data that must be scanned and authenticated regularly, I think that
the expression "good enough" must come into play, alas.  Otherwise, the
100% authoentication method will turn to 0% as the user simply stops
using it.

Ross M. Greenberg, Technology Editor, UNIX Today!   [e-mail]
             594 Third Avenue, New York, New York, 10016
 Voice:(212)-889-6431 BIX: greenber  MCI: greenber   CIS: 72461,3212
  To subscribe, send mail to [e-mail] with "Subject: Request"

------------------------------

Date:    Sat, 27 Jan 90 10:47:00 -0500
From:    [e-mail]
Subject: STONED Virus data (PC)

Response to Dave Lovless at UWO and Peter Jaspers-Fayer at Guelph:

Explanation of what STONED virus does and step-by-step instructions to
remove that virus from a hard disk can be found in:

[1] COMPUTERS & SECURITY - Volume 8, Number 1 on page 11 [2] CAS -
Volume 8, Number 2 on page 97 [3] CAS - Colume 8, Number 5 on page 369

All are part of my "Bits & Bytes" column in the journal of IFIP TC 11.
Received the first copy of that virus directly from John Beatson of Data
Systems in Wellington, New Zealand in October 1988.  Data Systems is
similar to our Federal Reserve System, only run by the banks.  John is a
close friend and is Manager of Risk and Security.

Bill Kinny of Digital Dispatch, Inc., producers of Data Physician [I ran
a review of product in February 1988 issue] and Virhunt and VirRes [scan
programs] wrote piece on how to remove STONED virus from hard disk.  His
code was checked in real-time by me; I infected one of our machines and
used his "cure" program.

Complete information about STONED, aka Marijuana, New Zealand, is
contained on pages 61 through 70 of COMPUTER VIRUS HANDBOOK just
published by Oxford Advanced Technology Press [publishers of COMPUTERS &
SECURITY] located in Oxford, England.

David Loveless at University of Western Ontario has copies of CAS as
does Professor John Carroll at UWO.  John should have a copy of COMPUTER
VIRUS HANDBOOK within two to three weeks.

If anyone cannot get their hands on CAS issues, contact David, John or
me.  Both CAS issues and COMPUTER VIRUS HANDBOOK contain step-by-step
explanation of how virus code works.  The HANDBOOK also has this data
for some 20 additional common viruses plus other information about this
subject.

- ----------------------------------------------------------------------------
Dr.  Harold Joseph Highland, FICS [FICS = Fellow of Irish Computer
Society] Distinguished Professor Emeritus of SUNY Editor-in-Chief
Emeritus of COMPUTERS & SECURITY Managing Director of International
Institute for Information
     Security Education and Training Highland -at DOCKMASTER.NCSC.MIL
MCI Mail 406-5012 Voice contact for emergency:  516-488-6868 EST
- ----------------------------------------------------------------------------

------------------------------

Date:    Sat, 27 Jan 90 12:52:02 -0800
From:    [e-mail]
Subject: WDEF Virus in California (Mac)

One of our Macintosh microcomputer labs was target of the new WDEF
virus despite intense daily anti-viral measures.  This warning is
posted especially for the other universities in Northern California.
Our staff are developing measures against this new virus.

Gerry Gray
Academic Computing Department
Humboldt State University
Arcata, California  95521
[phone], 4207, 4208

------------------------------

Date:    Sun, 28 Jan 90 15:18:47 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: More about UVDs

                Can an Universal Virus Detector (UVD) be written ?

In order to answer this question, we need to define just what is meant by
the term "virus".

We can start with the definition by Fred Cohen, from his "Computer Viruses:
Theory and Experiments":

        "We define a computer virus as a program that can infect
         other programs by modifying them to include a slightly altered
         copy of itself"

This definition is not perfect.

        "program" should also include boot sectors, INITs and all
        other forms of executable code.

        "include" must also cover cases like the 405 virus, that
        overwrite the victim, and may destroy it completely.

        "slightly altered" is much too inaccurate. It is easy to imagine
        a virus that would only include a small part of itself in the
        programs it infects. See note #1 at the end for details.

But is this modified definition just what we want ?  Consider the following
program.

                Program P1
                Display "This is a copy utility"
                Display "Name of input file ?"
                Input In-File
                Display "Name of output file ?"
                Input Out-File
                Copy In-File to Out-File
                End

Is P1 a virus ?

Well, according to our definition, it is. If we give it the name of itself
as In-File and the name of some other existing program as Out-File, it will
behave just like any other destructive overwriting virus. Since P1 is able
to place a copy of itself within another program, it is (according to this
definition) a virus.

So, any UVD would classify the above program as a virus.  In fact, it would
classify most operating systems as viruses, since they can easily "infect"
other programs in the same way - you just have to give them the right sequence
of commands.  Any compiler used to compile a copy of itself would also
qualify.

        "COMMAND.COM is a virus"
        "csh is a virus"
        "C is a virus"
        "OS/2 is a virus"     I like that one.....   :-) :-)

But is this what we want ?  Well - hardly.

The major reasons for not wanting to call P1 a virus are:

        1) It asks the user for the name of source and target files.
        2) It destroys the "victim", instead of executing it more
           or less normally, after executing the virus.

Objection 2 is not valid - as mentioned before we already have some programs
like 405 and the AIDS virus (not to be confused with the AIDS trojan), that
work like that. They are labeled as "viruses" without hesitation.

Let's change the program a bit:

                Program P2
                Display "Name of output file ?"
                Input Out-File
                Copy P2 to Out-File
                End

                Program P3
                Display "Name of input file ?"
                Input In-File
                Select Out-File at random
                Copy In-File to Out-File
                End

                Program P4
                Select Out-File at random
                Copy P4 to Out-File
                End

We probably want our UVD to tell us that P4 is a virus, but also that
P2 and P3 might behave like viruses in some circumstances.

But, and this is the all-important question, is it theoretically possible to
write a UVD that will tell us if a program may behave as a virus under
some circumstances ?

The UVD must always return with a "Yes" or "No".

The answer is Yes, if we make some assumptions:

        The program which is to be examined will be called P.

        The computer P runs on will be called C.

        The environment of P will be called E.

        E is assumed to contain the values of registers, memory and data
        in external storage.

        P is assumed to be of finite size.  Writing a UVD for programs
        of infinite length is impossible.  It is left as an exercise to
        he reader to determine the result if we have a multi-processing
        system, with an infinite number of processors, each running an UVD
        and throw an infinitely long program at it. :-)

        E is also assumed to be of finite size, with a specified maximum.
        This excludes Turing machines.  Writing an UVD for a Turing Machine
        is impossible, just as solving the halting problem for it.  We can,
        however, in theory determine if a program will halt on some input on
        some specific real-world computer.

        All I/O operations consist of the transfer of finite amount of data.

        The UVD program runs on a different machine, C*.  This machine must
        be many orders of magnitude more powerful than C. In fact, if C is
        a simple machine like Sinclair ZX80, with 1K of memory, C* would
        need to be more powerful than all current supercomputers combined.
        However, we must not be distracted by small problems like that. :-)

The proof itself is not included, since it is too lengthy, but if there is
interest I'll make it available.


                        Note #1 - Multi-Part viruses

Let us imagine we have the following three program parts

        Part A contains the main program

        Part B contains procedures for locating programs and making a
               program memory resident.

        Part C contains a file I/O routines.

Let us then create two programs, one containing A+B and one containing A+C.
If we only look at one of them, it is unable to replicate and (by definition)
not a virus.

Now the fun begins.

If we run a program containing A+B, it will not infect other programs.
It will however, hide a part of itself, namely B, somewhere in memory. and
then execute the original program.

If we run a program containing A+C, it is also unable to infect other programs,
but it can check if B is present in memory. If so, then we can combine A, B and
C in memory and run the combined program. It will use B to find all programs
not yet infected. They will the either be infected (using C) with parts A+B
or parts A+C. Repeat this for all programs that can be found by B. Then

The "virus" here is the program containing A, B and C, but as I said I would
demonstrate, it does not just include a "slightly altered" copy of itself in
other programs, but rather just an "inert" part. The virus will only activate
when its parts are combined.

- -frisk

------------------------------

Date:    Sun, 28 Jan 90 15:23:56 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Three new viruses (PC)

New virus:  Devil's Dance.

    Even though the name sounds as if this is a complex and interesting
    virus, it is not so. This virus is a very simple direct-action .COM
    infector reported to be from Spain.  It will add 941 bytes to the end
    of any file it infects and overwrite the first three bytes with a JMP
    to the viral code.  The virus may infect the same file over and over,
    just as the original Jerusalem virus did.

    Those of you having a copy of F-PROT can add the following line to
    SIGN.TXT, in order to enable detection of this virus:

Dance       BEbjA5tjKtmmT5mX4Kurg8uIgum4J628UGYOVjk5LOeDVjimIp


New virus:  Virus101

    This virus is written by the author of Virus90.  According to the
    documentation file, some changes have been made. The virus is now
    supposed to infect .EXE files and the boot sector, as well as .COM
    files.  From the documentation file:

                     VIRUS101 is the "big brother" of VIRUS-90.

           VIRUS-90 was a true non-overwriting virus designed to operate
           under the PC-DOS/MS-DOS operating systems.  VIRUS-90 was
           specifically designed to give both experienced programmers and
           novice computer enthusiasts experience in dealing with computer
           viruses.  VIRUS101, like VIRUS-90, is designed to educate the
           public on computer viruses, but is aimed more towards the
           programming populace.

    The author also states that the virus is tamper-proof and disassembly
    resistant.  This is of course absolute bullsh*t - it would probably
    take an experienced assembly language programmer less than an hour to
    create a harmful variant of it.  At least it took me only a few minutes
    to examine Virus90 enough to be able to write a program to detect it and
    remove it from infected files.

    The copy I have is labeled as pre-distribution and does not work. Since
    I no not include non-working viruses (like Pentagon) in my anti-virus
    program, I will not include this one yet.

    The author states that Virus90 and Virus101 are harmless, and he even
    has the nerve to ask authors of virus detection programs to

        "mention that both VIRUS-90 and VIRUS101 are educational utilities
         and that I have designed them for the benefit of programmers"

    and

        "include a short description of the programs for the good of the
         programming public.  Thanks for your help on this."

    But, the fact remains that this is a virus, and could very easily
    be turned into a very dangerous one. So, as soon as I get a working copy
    of it, I will update my programs to detect and remove it.

    Still, at least the author has agreed to stop selling the sources.


New virus:  1260

    There is no doubt about it - this is the most interesting virus
    to appear recently. It uses an encryption method similar to that
    used by Cascade (1701/1704), but there is one VERY important
    difference: It is not possible to use ordinary identification strings
    to find infected programs, since the longest sequence of bytes
    identical in all infected programs has a length of three!

    To demonstrate the problem, here are the first five instructions from
    three infected files:

       INC  SI             CLC                   MOV  AX,86FA
       MOV  AX,F69F        MOV  DI,0147          MOV  DI,0147
       NOP                 INC  SI               INC  SI
       MOV  CX,0550        CLD                   CLD
       CLC                 DEC  BX               DEC  BX

   The first 39 bytes of the virus are not encrypted, but they only
   contain 8 instructions, with a length of 17 bytes, for doing the
   actual decoding.  The rest is just garbage, mostly one-byte
   instructions like NOP, CLC, STC, CLD, INC SI, DEC BX etc, that have
   no effect on the program, but are only meant to confuse.

   The last "feature", which nobody had expected is that the eight
   encoding instructions are not always in the same order, but may be
   permuted in 24 different ways.  My virus detection program was not able
   to handle that, so I will have to create a new version - expect it in a
   day or two.

   "1260" is a resident .COM infecting virus. Infective length is 1260 bytes.

- -frisk

------------------------------

Date:    28 Jan 90 20:00:00 +0700
From:    [e-mail]
Subject: The V651 virus (PC)

                            The V651 Virus
                            --------------

        This virus can be considered as a teaching example (a state of
the art) of how to construct viruses.  It is only 651 bytes long (I
have named it V651 or Eddie-2, you will see later why) but contains
solutions of almost all problems which a virus designer may encounter.

        The virus attacks both .COM- and .EXE-files.  They are
infected when you start them and the .EXE-files are distinguished from
the .COM- ones by the `MZ' marker in the first two bytes.  So you
cannot fool the virus by renaming your *.COM files to, say, *.CMD and
*.EXE to *.EXX and fixing the default extensions in COMMAND.COM.

        To be infected, the files must have a length larger than 651
and smaller than 64372 bytes.  The virus installs itself in the memory
by manipulating the memory control blocks, so it cannot be seen with
such utilities as the public-domain MAPMEM.  However, by using PC
Tools (F3, system Info), you can see that the amounts of available
memory found by PC Tools and by PC-DOS differ by 1 K byte (e.g., 640
and 639). (WARNING! I know at least 3 computers which show the above
difference but have no viruses --- maybe sometimes this difference may
be caused by the strange firm/hardware.)

        The virus' marker is like the one of the VHP-648 (Vienna A,
Austrian) --- 62 seconds in time-of-last-update field of the directory
entry for the infected files.  This makes possible to design a vaccine
(just like for the VHP-648 virus).  One has simply not to forget to
vaccinate both the .COM- and the .EXE-files.  I'm wondering why the
virus author did not made his virus three bytes shorter (which is
possible) --- just to make it look like the VHP-648 one.

        When in memory, this virus intercepts two PC-DOS functions ---
find-first (FCB) and find-next (FCB).  They return various information
about the respective directory entry --- its name, size, date and time
of last update and so on.  When an entry for an infected file is
encountered (which is recognized by the time-of-last-update field),
the virus changes the information in the `size' field, by subtracting
651 (its own size) from it.  So if you type DIR with the virus
resident in memory, you will obtain a directory listing with the
original (non-infected) file lengths.  This reduces the chances to
discover the virus.

        The virus has his own critical error handler, so you won't get
the "Abort, Retry, Ignore? " message when it tries to infect a write-
protected diskette.

        However, the virus' author has made two mistakes.  First, the
virus does not intercept the find-first/find-next functions which are
using the file handle (instead of FCBs used by DIR) method.  So, if
you look at a directory with a file-manager utility, you will almost
certainly notice the increased file lengths.  Second, if you already
have a small (under 651 bytes) .COM-file, which is vaccinated against
the VHP-648 virus and the V651 virus is resident in memory, you will
obtain a huge number for the file length when listing the directory
with the DIR command.

        The virus has no destructive functions.  In fact it does not
have any effects at all.  The string "Eddie lives" is contained in its
body but is never displayed.  (The string contained in the original
Eddie or Dark Avenger virus is "Eddie lives...somewhere in time!".)
Obviously, the author of the V651 virus was envious for the faith of
the Dark Avenger.  Of course, this reveals also the fact that this
virus was created in Bulgaria (I do not know its author).

        Just like the Eddie (Dark Avenger) virus, this one saves the
critical information from the infected files in the last 11 bytes of
its code.  They have the following layout:

                IP (2 bytes) - The contents of the IP field of the
                               EXE-header
                CS (2 bytes) - The contents of the CS field of the
                               EXE-header
                SP (2 bytes) - The contents of the SP field of the
                               EXE-header
                SS (2 bytes) - The contents of the SS field of the
                               EXE-header
                (3 bytes)    - The first 3 bytes of the file

        The (IP, CS, SP, SS) fields are used when an infected .EXE-
file is run and the last 3 bytes are for the .COM-files. So, if you
want to disinfect (cure? I'm not sure for the right word) an infected
file, you have to restore the original contents of the .EXE-header
(resp. - the first 3 bytes of the .COM-file) from the last 11 bytes
described above and then to shorten the file by 651 bytes.

                        Sincerely,
                                        Vesselin Bontchev

------------------------------

Date:    29 Jan 90 05:40:13 +0000
From:    [e-mail] (Gene Spafford)
Subject: Re: Virus vs. worm

hp-sdd!hplred.HP.COM![e-mail] (Jeff Perry) writes:
>   This is probably a simple question, but I haven't heard it asked (or
>answered). What is the difference between a virus and a worm?

Well, there are many differing definitions, with one extreme being
that all worms are viruses.

The definitions I think most people use are:

  A virus is code that cannot run on its own.  It is inserted into
another ("host") program, and cause that program to run the virus
code when the host is run.  The virus code, when run, will insert a
copy of itself in another "host," then possibly do some other task
(often known as the "manipulation" task), then possibly execute the
original host code.  Viruses are not self-contained programs.

  A worm is a program that can run by itself.  It is self-contained in
that it can run as an independent program.  It may use system programs
to propagate itself.  Worms travel (and possibly multiply) over
communications links.  They do not necessarily do anything other than
travel from machine to machine (or propagate around a network), but
they may also perform manipulation tasks, carry viruses, etc.

Gene Spafford
NSF/Purdue/U of Florida  Software Engineering Research Center,
Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-2004
Internet:  [e-mail]   uucp:   ...!{decwrl,gatech,ucbvax}!purdue!spaf

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Tuesday, 30 Jan 1990    Volume 3 : Issue 25

Today's Topics:

PC Magazine Free Utility: PCDATA (PC)
ADAPSO Virus Book
Security and Internet Worms (Source Code)
Article on Cliff Stoll
Did Morris try to stop the worm?
Yet Another WDEF Infection (Mac)
VAX Virus request and UMNEWS (general)
Yankee Doodle Virus
Prophylactic anti-viral suggestion
Possible new virus?? NUCLEUR WAR.
Universal virus detectors
Re: Virus request
Re: Virus request
Re: WDEF at University of Rochester (Mac)
re: 'Virus request' from Taiwan
WDEF Infection (Mac)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

---------------------------------------------------------------------------

Date:    25 Jan 90 11:53:00 -0500
From:    "zmudzinski, thomas" <[e-mail]>
Subject: PC Magazine Free Utility: PCDATA (PC)

PC Magazine, Vol 9 No 3, February 13, 1990, pp. 263-283, contains an
article by Wolfgang Stiller, "Protect Your Data with PCDATA, the Data
Integrity Toolkit".  Stiller has put together an impressive array of
eight (8) programs and nineteen (19) BAT files designed "to detect and
recover from all data integrity threats, including viruses".  This
toolkit is available "free" (i.e. no-fee bannerware) from "PC MagNet"
on CompuServe.  (Buy the magazine to get the documentation.)

Would one or more of our virus gurus please download these utilities
and try them out?  I'm sure we'd all like to know how these stand up
to various viruses.

/s/ Tom Zmudzinski                      Standard Disclaimer:
    DCS Data Systems                   "Shill for these people?
    McLean, Virginia                    Heck, I don't even know them!"

TomZ @ IMO-UVAX.DCA.MIL

------------------------------

Date:    Mon, 29 Jan 90 10:58:50 -0500
From:    Gene Spafford <[e-mail]>
Subject: ADAPSO Virus Book

"Computer Viruses: Dealing with Electronic Vandalism and Programmed
Threats" by Eugene Spafford, Kathleen Heaphy, and David Ferbrache.
1989, 109 pages.  Published by ADAPSO.

The book has been written to be an accessible resource guide for
computer users and managers (PC and mainframe).  It presents a
high-level discussion of computer viruses, explaining how they work,
who writes them, and what they do.  It is not intended to serve as a
technical reference on viruses, both because the audience for such a
work would be limited, and because such a reference might serve to aid
potential virus authors.

The goal of the book is to dispell some common myths about viruses
(and worms, trojan horses, et. al.), and provide simple, effective
suggestions for how to protect computer systems against these threats.
It furthermore stresses that most systems face greater threats from
other areas, so the proper attitude to take is to strengthen overall
security; concrete suggestions for enhancing overall security are also
presented.

The appendices provide extensive references to other publications,
security organizations, anti-viral software sources, applicable (U.S.)
state and Federal laws against computer crime, and detailed
descriptions of all IBM and Apple Macintosh viruses known as of 1
October 1990.

Although written for ADAPSO members, almost any computer user should
find it instructive.  The appendices are an excellent source of
further information, addresses and phone numbers, and pointers to
software.  At least one university professor has indicated he will use
the book in a security course, and some law enforcement agencies are
also considering using the book for instructional purposes.

The authors are interested in comments and feedback about the book,
especially in areas where information might be added.  You can contact
them by sending mail to "[e-mail]"

Table of Contents:
  Preface
  Executive Summary
  Introduction
  Programmed Threats
    Definitions
    Damage
    Authors
    Entry
    Summary
  What is a Computer Virus?
    Names
    A History Lesson
    Formal Structure
    How do viruses spread?
    The three stages of a virus's life
    Replication strategies
    Recognizing a viral infection
  Dealing with Viruses
    Prevention
    Detection of a viral infection
    Recovery
    Summary
  Security
    A definition of security
    Security as a goal
    Risk assessment
    Some General Approaches
    Summary
  Legal Issues
    Criminal laws
    Civil suits
    Summary
  Attitudes
  Further Information on Viruses
    Characteristic lengths
    Names of Known Viruses
    Known IBM PC viruses by Characteristics
    Known Apple Macintosh Viruses
    Characteristic resources for Mac viruses
  Information on Anti-Viral Software
    Selected reviews of Anti-viral Software
    Easily obtained software
    Internet Archives
    Other Places to Look
  Further Information on Legal Aspects of Viruses
    Federal Laws
    State Laws
    Other Sources of Information
  Further Reading and Resources
    Organizations and Associations
    Government Agencies
    Journals and Newsletters
    Other Readings

A copy can be ordered from
        ADAPSO
        1300 North Seventeenth St.
        Suite 300
        Arlington, VA 22209  USA
        Attn: Mr. John Gracza

Single copies are $30.  Copies ordered on university stationary or on
stationary of ADAPSO member companies is only $20, and $16 for the
second and subsequent copies.

Requests for review copies or special considerations should be
addressed directly to John Gracza.  Copies have been given away to
ADAPSO member companies, and various state and Federal law enforcement
agencies, so check with others in your organization to see if a copy
isn't already available for review.

Overseas orders will be shipped surface mail.  Overseas orders that
are to be shipped air mail should include an additional $10 for
postage.

All payment should be in US dollars, no cash or stamps.


------------------------------

Date:    29 Jan 90 13:24:00 -0400
From:    "Andrew D'Uva" <[e-mail]>
Subject: Security and Internet Worms (Source Code)

It seems that the information revolution has brought with it great
problems.  These vast interconnected networks and systems now allow us
to transfer data and programs quickly and at little cost.  The problem
lies in the fact that their level of integration opens them to
infection by worms and trojen horses.  We have even had people ask for
source code for these programs!  Is the solution, as Don Ingli wrote,
to set up some form of reporting mechanism to track these requests?

Sadly, I believe it is.  In the United States a certain level of
privacy has been granted as a constitutional right.  That privacy,
however, is not given rights status when it may be demonstrated to
contravene the public good.  In the case of willful and malicious
network destruction/overload/etc, we can only hope that the network
authorities will take pains to trace these people.  The problem, as I
see it, is that no unified network authority exists.  We can hardly
expect to fight the problem without a centralized "clearing house" for
virus information.  This list serves as one such clearing house.

However--we still have not (as far as I know) set up a worldwide
security group dedicated to addressing problems like these.  Internet
is so large that this would be hard to do.

Yes, I believe that viral source code ought to be distributed and
studied-but under controlled conditions.  The universities offer the
best hope of such a controlled setting.  These problems must be
addressed.  If, as we do in national security issues/clearances, the
focus remains on preventing the outflow of information we risk losing
these battles.

-
 -------------------------------------------------------------------------------
- -
Andrew D'Uva
Georgetown University
Washington, D.C.
   Internet: [e-mail] or [e-mail]
   Bitnet  : ADUVA@GUVAX
 CompuServe: 76106,3120

------------------------------

Date:    29 Jan 90 21:50:16 +0000
From:    [e-mail] (Mary Ellen Lee)
Subject: Article on Cliff Stoll

I hope someone will correct me if there's a better newsgroup for this:

The February issue of Smithsonian magazine has a breezy little article
on Cliff (Cuckoo's Egg) Stoll. Nice coverage of the man, the book, and
the "popularization" of computers in general. It's on page 20.

------------------------------

Date:    Mon, 29 Jan 90 09:08:48 -0800
From:    Jim Gillogly <[e-mail]>
Subject: Did Morris try to stop the worm?

Geof Cooper said:
> One thing that makes me wonder: A newspaper article claims that Morris
> wanted to stop the worm when it started to get out of control, and
> decided that he wasn't able to.  When the Internet group started to
> try and control it, why didn't he offer to help?

The following message was sent the morning after the network worm started.
My understanding is that it was sent by a friend of Morris.  Checking the
"Received" times suggests that it it didn't arrive in time to do any good.

        Jim Gillogly

 --------- Forwarded message -------------
Received: from SRI-NIC.ARPA by rand.org; Sat, 5 Nov 88 03:20:10 PST
Received: from RELAY.CS.NET by SRI-NIC.ARPA with TCP; Fri, 4 Nov 88 23:23:24 PS
T
Received: from cs.brown.edu by RELAY.CS.NET id aa05627; 3 Nov 88 3:47 EST
Received: from iris.brown.edu (iris.ARPA) by cs.brown.edu (1.2/1.00)
        id AA12595; Thu, 3 Nov 88 03:47:19 est
Received: from  (128.103.1.92) with SMTP via tcp/ip
          by iris.brown.edu on Thu, 3 Nov 88 03:34:46 EST
Message-Id: <[e-mail]>
Date: Thu, 3 Nov 88 03:34:13 EST
From: [e-mail]
To: [e-mail]

A Possible virus report:

There may be a virus loose on the internet.

Here is the gist of a message Igot:

I'm sorry.

Here are some steps to prevent further transmission:

1) don't run fingerd, or fix it to not overrun its stack when reading
arguments.

2) recompile sendmail w/o DEBUG defined

3) don't run rexecd

Hope this helps, but more, I hope it is a hoax.
qui

------------------------------

Date:    Mon, 29 Jan 90 13:01:38 -0500
From:    "Gregory E. Gilbert" <[e-mail]>
Subject: Yet Another WDEF Infection (Mac)

WDEF A has made it to The University of South Carolina.  So far I have
only seen one person who has been infected.  I am sure their will be more.

If anyone has any ideas how to control it in our Microlabs I would
appreciate hearing from them (any other experiences too.)  Thanks and
happy hunting.

Greg

Postal address: Gregory E. Gilbert
                Computer Services Division
                University of South Carolina
                Columbia, South Carolina   USA   29208
                [phone]
Acknowledge-To: <C0195@UNIVSCVM>

------------------------------

Date:    Mon, 29 Jan 90 18:24:57 -0500
From:    [e-mail]
Subject: VAX Virus request and UMNEWS (general)

Hi,

     Having been a UMNEWS user for 2+ years, I thought that VIRUS-L
should know that ALL users of UMNEWS are required to register by E-MAIL
in order to use the service.  When a new user issues the REGISTER
command the first time, they are sent a copy of the policy for using
UMNEWS.

     The policy states explicitly that illegal and unethical use
of UMNEWS will not be tolerated.  It also states that in registering,
the user has read and understood the policy document.

     Clearly the request for a VAX virus was in direct violation of
the UMNEWS policy and the requestor stands a good chance of losing
all access to UMNEWS.

     The policy document is available from UMNEWS@MAINE on bitnet.
The file name is UMBB POLICY

                       Andy Wing
                       Senior Analyst
                       Temple University School of Medicine

------------------------------

Date:    Mon, 29 Jan 90 17:06:20 -0400
From:    "Ghassan N. Alkhoja" <[e-mail]>
Subject: Yankee Doodle Virus

To all Virus experts,

Does anyone out there have any experience with the Yankee Doodle virus.
One of the departments on-campus here at GWU is infected with that virus.
I would appreciate all help that you can provide. Thank you.

Ghassan N. Alkhoja
Sr. Programmer/Analyst
Computer Information and Resource Center
The George Washington University

------------------------------

Date:    29 Jan 90 19:19:22 +0000
From:    [e-mail]
Subject: Prophylactic anti-viral suggestion

Dear net friends,

   here is a suggestion which may help protect against trojans and viruses --
I haven't seen it mentioned on virus-l (although I've only been reading
it since the start of the Aids scare - the first time I've been personally
affected by viruses) so if I'm repeating an old idea please forgive me.

   I use a computer made in the UK called the Acorn Archimedes -- it is a
proprietary RISC cpu, but I can use it with MSDOS programs because it comes
with a pretty good MSDOS emulator: a combination of a CPU emulator, device
emulator, and operating system emulator. (The device emulator attempts to
pass low-level calls like disk i/o through to the Archimedes' disk controller,
the MSDOS emulator runs an emulated ROM but also passes some BDOS commands
through to the host filing system -- for instance, drive F: could come off
a network drive in Archimedes format, not MSDOS.  [The various parts
of the emulation are all implemented in software, I should make clear...]

   It occurred to me that a similar program could be run on a *genuine*
MSDOS machine in order to provide a safety wrapper around any programs
which were run on that machine.  (Ie it would still be an emulator, but
it would have a head-start in performance because the emulated CPU &
the real CPU were very similar :-) )

   This 'emulator' (I'll call it a 'CPU condom' from now on) would therefore
be able to guarantee that any memory access only came from emulated memory --
no program would be able to muck around with real memory.  It would only allow
access to the devices which the user chose to allow (eg, clock - yes,
disk controller - no); and it would trap all higher-level BDOS/BIOS calls
in order to ask the user (say by switching to an alternate screen display
and back again) whether he/she wanted to allow any particular file to
be written to.

   The CPU condom would probably not be able to allow a full 640K to
the running program - I don't know - that's for MSDOS experts to work out.
With a program like this, you would be able to run any unknown code
with complete confidence.  It could be parameterized so that particular
programs being run always were allowed to write only to specific directories,
to save users having to say 'yes' or 'no' every time a file was being
written.

   Unfortunately, I don't have the expertise to write this myself, (I
know very little of MSDOS or 808X's and really don't want to waste brain-cells
learning it ;-) )  but the readership of this list is sufficiently wide
that writing such a system may appeal to someone.

Over & out,
  regards,
    Graham Toal   <[e-mail]>

PS If written portably, an MSDOS emulator which did solely file I/O
and screen/keyboard I/O would be usable on other systems -- especially
useful for things like unpacking self-extracting .exe files on unix
mainframes -- almost impossible otherwise.  (I have countless numbers
of archive unpackers on our local Unix machine to save telephone
bandwidth when I fetch something from a server and discover I only
want 15% of the archive it came in!)

------------------------------

Date:    30 Jan 90 01:03:10 +0000
From:    munnari!dbrmelb.oz.au![e-mail] (Stephen Oakes)
Subject: Possible new virus?? NUCLEUR WAR.

A Friend Of A Friend had this happen on his XT upon booting from the
Hard Disc.  A message appeared saying something like:

"    Welcome Home !!!!
     I have had a good rest, have you?

     Now, lets get down to business.

     Do you want ...  THERMO NUCLEUR WAR!

     Press any Key to continue.
"

(I'm not sure if "NUCLEAR" was originally mispelt, or copied down
incorrectly)

The FOAF immediately switched his computer off, and is now preparing
to reformat his Hard disc.  If this is a virus, it probably came form
games software which the FOAF copied from A Friend.  I know nothing
about where the FOAFOAF gets his software.

    Anyone know anything about this one?

Stephen Oakes : [e-mail]

------------------------------

Date:    Mon, 29 Jan 90 23:34:00 -0500
From:    [e-mail]
Subject: Universal virus detectors

All this debate about whether virus detection is equivalent to the
halting problem, whether real CPU's are best modeled and FSA's or
Turing machines, and so on, is interesting but in a deep sense
completely irrelevant.

With simple hardware support, one can design a system in which all
viruses are trivial detectable.

        Technique:  The hardware will maintain, in both memory and
        on disk, an "is executable code flag".  For practicality,
        assume this is done on a block-by-block basis say in units
        of a K.

        The hardware enforces the following rules:

        1.  Any attempt to execute code from a memory block which
        is not marked executable fails.

        2.  The only way to write into a block of memory that is
        marked executable is from a disk block marked executable.

        3.  Any attempt to write to a disk block marked executable
        fails.  (To write to such a block, the executable flag must
        first be cleared.)

        4.  Any disk block can be marked executable at any time.

        Memory blocks are marked executable only by reading execu-
        table disk blocks into them.

        5.  Associated with every disk block is a time stamp.  When
        a block is marked executable, the hardware updates its time-
        stamp.

        6.  The system comes with physical ROM blocks, marked exe-
        cutable, which contain at least the code needed to display
        the timestamps on all executable blocks.

One could obviously come up with a simpler system - e.g., just keep a
timestamp on EVERY block - but this one is close to practical.  The
sticky spot is 4, which makes it impossible to build executable code
without going through the disk.  Building disk caches for such a
system would also be a complex undertaking.  On the other hand, the
rules are so simple that one could attain a very high degree of
confidence that the hardware was enforcing them correctly.

Why does this work, despite all the proofs?  (Note that it works just
fine even if the disk is assumed to be infinite, in which case the
machine is a Turing machine.  If you are worried about the theoretical
problem of repeated time-stamps - just use variable-length
time-stamps, which are no problem on an infinite disk.)  It works
because none of the standard models have anything that corresponds to
the timestamp: Memory that can be written by the system, but not by
externally-controllable code within the system.

                                                        -- Jerry

------------------------------

Date:    30 Jan 90 04:45:11 +0000
From:    [e-mail] (A J Annala)
Subject: Re: Virus request

>> >        Dose anyone have a idea about VAX Virus? Or interesting on
>> >        it? I think the most difficult point is how to spread it
>> >        out. So if someone has any bright idea, contact with me.
>
>What as a whole can the computer industry do to help prevent individuals
>like this from the potential releasing of these viruses(viri?) into the
>vast networks??  Should it be illegal to own or transmit virus source
>(for non-security personnel)??  Also, should there be an international
>watchdog agency set up to investigate such requests??  Should the
>CIA/FBI/FCC be involved in cooperation with IBM/DEC/AT&T/etc.. to form a
>task force along with our list's virus expert?  Has anyone contacted this
>person's administration along with MAINE's and BITNIC/BITNET administration?
>Right now, its up to us to report these requests and its the responsibility
>of MAINE to act on requests submitted via UMNEWS.
>
>Can we make it illegal to have virus sources without stomping on our
>constitutional rights??  What about other countries??
>
>Obviously this particular Taiwanese knows little about VAX networking and
>uses of viruses(worms) in those networking facilities.

There are people who write computer programs (including viruses) and there
are people who only use computer programs (including viruses).  It would
appear that the originator of the request for a VAX Virus is a member of
the latter group.  While it is rather amusing that the requestor could be
so terribly naive as to post his note to a public newsgroup, I seriously
doubt he would be sufficiently competent to introduce a virus into DECNET,
SNA, TCP based networks.  Calling out the computer gestapo in this case may
seem a little heavy handed.  Perhaps someone would consider sending him a
friendly note explaining the damaging potential of actually introducing one
of the responses to his request into a live computer network.  One might be
tempted to highlight the potential administrative/regulatory response to the
actual use of the information gleaned from his request.

NO.  One cannot forbid the possession of sources, linkable objects, or even
executables for a virus without doing fundamental harm to the Bill of Rights.
Viruses may be an unpopular idea ... but the protection of the right of the
individual to free expression of his ideas ... and the right to share those
ideas with other people is fundamental to the concept of a free society.  If
one encroaches on the fundamental right of free speech (including writing)
then one does fundamental damage to our constitutional guarantees.  Moreover,
even if you would allow such a prohibition in spite of it's constitutional
implications, the regulation would most likely be unenforceably broad.  It
would be all but impossible to distinguish the program category "virus" from
other less virulent programs.  Let's keep to prosecuting harmful use of such
material rather than mere possession of unpopular ideas.

AJ

------------------------------

Date:    30 Jan 90 06:34:49 +0000
From:    khijol![e-mail] (Ed Carp, aka Mr. Ed the talking horse...)
Subject: Re: Virus request

woodb!scsmo1![e-mail] writes:

>He will probably get a few replies as well as some sources. What as a
>whole can the computer industry do to help prevent individuals like
>this from the potential releasing of these viruses(viri?) into the
>vast networks??

 Not a whole lot, except to take reasonable security precautions.

>Should it be illegal to own or transmit virus source (for non-security
>personnel)??

 No.  How would you define the term "security personnel"?  I can write
a virus with a little effort.  Does this make me a criminal?  Of
course not!  Similarly, I have a complete set of lockpicking tools.
Does this make me a criminal?  Again, the answer is no.  It's not the
tool, it's the use of the tool.  Remember, you can design a workable
atomic bomb from documents that you can find at most any large public
library.  Why should it be different for anything else?  Let's not get
swept up in this anti-virus hysteria -- let's see some reason.

>Also, should there be an international watchdog agency set up to
>investigate such requests??  Should the CIA/FBI/FCC be involved in
>cooperation with IBM/DEC/AT&T/etc.. to form a task force along with
>our list's virus expert?

I think this is going a bit overboard.  Sounds like paranoid hysteria.

>Has anyone contacted this person's administration along with MAINE's
>and BITNIC/BITNET administration?

>Right now, its up to us to report these requests and its the
>responsibility of MAINE to act on requests submitted via UMNEWS.

 Really?  Who appointed "us" net.police?  Or net.censor?

>Can we make it illegal to have virus sources without stomping on our
>constitutional rights??  What about other countries??

 I doubt it.

Right after the Internet virus was released, I saw several postings
requesting source for the virus.  Sure, there were probably net.idiots
who wanted to take the source, hack it up, and re-release it, but
there were obviously sincere, rational investigators who wanted to
investigate the virus, tear it apart, figure out just how it worked,
and then build a better virus-catcher.  There are people who are out
there who make money by doing this sort of thing.  Are you suggesting
that the people who have already become established (known) in the
field have some sort of exclusive on source?  Who appointed Gene
Spafford the net.virus.god?  This is NOT a flame against Gene, but I
have a dim view of folks who want to set up Gene and others like him
on a pedestal.  I respect Gene's abilities in his field, but there are
lots of programmers who can do the same thing.

If someone wants to write a virus, he can sure do it without having
access to source.  Who's going to judge?  If I ask for source (hey,
Gene, can you mail me the latest source to the Internet virus?), does
that make me automatically suspect?  Am I a "bad guy"?  I could forge
my mail address, looking like I come from IBM's Virus Research Group
(thinking about it, I don't really *need* to forge THAT), send Gene a
request, then, when I get the source, use it for my own nefarious
purposes.  Alternately, I could be doing genuine virus research for
defending AIX against viruses.  There IS such work going on, you know.

I could even be legit.  I sub-contract for IBM.  This gives me access
to IBM's facilities, phones, etc.  I could pose as a virus research
(or even BE a virus researcher), get the source, and do whatever.

Just because one is a "security expert" doesn't make them a "good guy"; just
because one isn't doesn't make them a "bad guy".
- --
Ed Carp                 N7EKG/5 (28.3-28.5)     uunet!cs.utexas.edu!khijol!erc
Austin, Texas           [phone]          "Good tea.  Nice house." - Worf
"Love in any language, fluently spoken here"             -- sung by Sandi Patti

------------------------------

Date:    30 Jan 90 05:22:52 +0000
From:    [e-mail] (Wing Leung)
Subject: Re: WDEF at University of Rochester (Mac)

        WDEF B is found in University of Rochester.  Tonight I've found
one of my disk crash due to a problem in the Desktop file.  After recovering
it at the Computer Center, we use Disinfectant 1.5 to scan the Desktop file
and WDEF B is found.  My friend use it to scan his disks too.  The earliest
infection found so far is on 22nd Jan.

Peter

  _    _  ____  ____   _        * Internet:     [e-mail]
 (/   /  //  / //   ) (/        * BITNET  :     WCPL_LTD@UORDBV
 / / /  //    //___/ _/         * DecNet  :     UORHEP::PETER
/_/_/  //__/ //     _/\___/     * UUCP    :     ...rochester!uhura!wcpl_ltd

------------------------------

Date:    Tue, 30 Jan 90 11:54:32 +0000
From:    "Dr. A. Wood" <[e-mail]>
Subject: re: 'Virus request' from Taiwan

......Re this message:-
From:  IN%"[e-mail]"  "Vax discussion" 21-JAN-1990 23:11:59.77
Subj:  <Vax 85> Virus on VAX
From: [e-mail]

Hi! Does anyone have a idea about VAX Virus? Or interesting on it? I
think the most difficult point is how to spread it out. So if someone
has any bright idea, contact with me. James Huang

......and this reply to it:-
Date:    Thu, 25 Jan 90 12:08:35 -0500
From:    woodb!scsmo1![e-mail]
Subject: RE: Virus request

Here is a message from UMNews's Vax discussion list. I thought the
list should know about this. The node is Taiwanese.  This is insane.
Obviously this particular Taiwanese knows little about VAX networking
and uses of viruses (worms) in those networking facilities. He will
probably get a few replies as well as some sources. What as a whole
can the computer industry do to help prevent individuals like this
from the potential releasing of these viruses into the vast networks??
Should it be illegal to own or transmit virus source (for non-security
personnel)?? Also, should there be an international watchdog agency
set up to investigate such requests?? Should the CIA/FBI/FCC be
involved in cooperation with IBM/DEC/AT&T/etc.. to form a task force
along with our list's virus expert? Has anyone contacted this person's
administration along with MAINE's and BITNIC/BITNET administration?
<etc etc>
.............................................................................

If James Huang is Taiwanese, then his first and most familiar language
is likely not English but Chinese, and likely he committed no computer
ethical error but merely a language blunder, namely the common capital
offence of 'unclear use of a pronoun'!  <WOODB!SCSMO1![e-mail]>,
in the course of emptying his  flamethrower down the  computer link at
the  unfortunate Huang, seems to   imply that Huang   meant "I want to
spread VAX virus".  But Huang could also have intended to say  "I want
to spread news about how to notice and combat VAX virus"

- - which is what Virus-L is for!!
{A.Appleyard} (email: [e-mail]), Tue, 30 Jan 90 11:25:08 GMT

------------------------------

Date:    Tue, 30 Jan 90 08:18:29 -0500
From:    Jim Ennis <[e-mail]>
Subject: WDEF Infection (Mac)

Hello,

  We had a WDEF infection of our Mac lab at the University of Central
Florida.  The person fixing the viruses traced the source back to a
local copy center which has some Mac for use on a hourly basis and
students brought their infected disks from the store to our Mac lab.
The person who kills viruses for us has cleaned up the Macs in our
lab.

 -----------------------------------------------------------------------------
 Jim Ennis
 UCF - Computer Services
 [e-mail]

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Tuesday, 30 Jan 1990    Volume 3 : Issue 26

Today's Topics:

ATM Bankcard Security
New files to MIBSRV. (PC)
library virus (PC)
confirmation on library disk infection (PC)
Re: Innocent Until....
Public PC lab responsibility
Re: Virus request
Anti-virus suite
Re: Signature Programs

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

---------------------------------------------------------------------------

Date:    Mon, 29 Jan 90 21:38:20 -0500
From:    [e-mail]
Subject: ATM Bankcard Security

   Bernie Cosell <[e-mail]> writes:

>Similarly, with ATM cards, the primary 'line of defense' is some
>security-by-obscurity encoding on the card and a three-digit password
>[which, I think, is also encoded on the card].

As I understand it, the PIN (Personal Identification Number) is not
stored on the ATM card, but is retrieved by the ATM and compared with
the number entered on the ATM keypad.  The ATM machines are on a wide
area network, and I don't know if the PIN is actually transmitted, or
if the result of some algorithm applied to PIN is sent (the latter, I
hope!).  Also, the PIN is four digits (or at least mine is).

David Conrad ([e-mail])
"If all else fails, immortality can always be assured by spectacular error."
                             -- John Kenneth Galbraith

------------------------------

Date:    Tue, 30 Jan 90 08:36:04 -0600
From:    James Ford <[e-mail]>
Subject: New files to MIBSRV. (PC)

These files have been placed on MIBSRV.MIB.ENG.UA.EDU (130.160.20.80)
for anonymous FTP.  They are:

SCANV57.ZIP   -   ViruScan 2.7V57 (update)
SCANRS57.ZIP  -   TSR version of ViruScan (update)
NETSCN57.ZIP  -   Network Version of ViruScan (update)
CLEANP57.ZIP  -   Clean-Up Virus Remover (update)

NETFIX10.ZIP  -   Equivalent to NETSCAN & CLEAN-UP (*new*)

All files were downloaded directly from Homebase BBS on 1/29/90
- ----------
    James Ford - [e-mail], [e-mail]

------------------------------

Date:    Mon, 29 Jan 90 15:31:17 -0700
From:    [e-mail] (Richard Caasi)
Subject: library virus (PC)

VIRUS ALERT!!  Here's a message from Steve Palincsar at the GAO about a
verified virus in a depository library shipment.  Please note and repost this
wherever it might be read earliest...

Depository libraries have received notification from Regional Depositories
and the U.S. Goovernment Printing Office that depository shipment #900057-p,
which contains a CD ROM disk of census statistics from the census bureau and
two floppy diskettes of software to access the CD disk contains a diskette
(labeled "2 of 2") which is contaminated with the Jerusalem Virus.  Recip-
ients are urged to destroy disk "2 of 2" immediately, and are warned that
the Jerusalem Virus can destroy data on their entire system.  We were notified
by Hugh O'Connor of the Univ. of MD REgional Library; I called him and con-
firmed the authenticity of the call we'd received, and then followed up by
calling Joe McLean [spelling unconfirmed], Chief of GPO's Inspection Team
(202-275-1119) who also confirmed the authenticity of the report.  Shipment
#900057-P was mailed 1/25/90.  There were no details about how replacement
software would be supplied for the contaminated diskettes.

Nancy Garman, Editor, ONLINE (606)331/6345

[Ed. See next message for more info.]

------------------------------

Date:    Tue, 30 Jan 90 14:29:04 -0500
From:    Kenneth R. van Wyk <[e-mail]>
Subject: confirmation on library disk infection (PC)

I phoned the folks at the GPO and confirmed that the above report is
indeed true.  They faxed me a copy of a letter which they're sending
out to the people that they know have received the disks.  Below is a
(transcribed - sorry if there are typos) copy of that fax.

Ken

===== Cut Here =====

Dear Depository Librarian:

GPO has just been notified by the Census Bureau that one of the floppy
disks just distributed by GPO with the _County and City Data Book_
CD-ROM is infected with a computer virus AND SHOULD NOT BE USED UNDER
ANY CIRCUMSTANCES.  The floppy disk was listed on shipping list
90-0057-P as C 3.134/2:C 83/2/988/floppy-2.  The title on the floppy
disk reads as follows:

Bureau of the Census
Elec. County & City Data Bk., 1988
U.S. Stats., Inc., 1101 King St.,
Suite 601, Alexandria, VA 22314
[phone]

PLEASE DESTROY THE FLOPPY DISK AS SOON AS IT IS RECEIVED.  (Do NOT
reformat and reuse the floppy disk.)

The virus has been identified as the Jerusalum-B virus (also referred
to as the Israeli virus).  It infects any .COM or .EXE program on
MS-DOS personal computers and increases program size by approximately
1,800 bytes.  Other programs are infected when they are executed in an
infected system.

The Jerusalum virus can cause significant damage on an infected
personal computer.  It generally slows down the system and some
versions destroy all data on the hard disk.  .EXE files continue to
grow in size until they are too large to execute.

If your computer has already been infected, we recommend that, if
possible, you seek assistance from a computer specialist at your
institution immediately.  There are special programs available for
detecting and eradicating computer viruses.  One may be available in
your institution or from someone you know.  DO NOT USE YOUR PC TO
ACCESS A NETWORK OR PRODUCE FLOPPY DISKS CONTAINING .EXE OR .COM
PROGRAMS FOR BY OTHER PCS.

The _County and City Data Book_ CD-ROM can be used safely with the
software on the other floppy disk disk distributed in that shipment
((C 134/2:C 83/2/988/floppy).

If you have any questions, please call Jan Erickson at GPO (202
275-1003) or the Census Bureau Customer Service at (301 763-4100).

The Census Bureau and GPO regret any problems that this may have
caused.  Appropriate measures will be taken to ensure that it does not
happen again.

------------------------------

Date:    Tue, 30 Jan 90 09:47:00 -0500
From:    <[e-mail]>
Subject: Re: Innocent Until....

>>As of the time of your posting, what judicial process has
>>concluded with a finding of fact that he released the worm?

>I wondered whether or not anyone would challenge that
>assertion.
>
>As of the time of my posting, The New York Times had already reported
>Morris had so testified.
>
>As of the time of the original assertion to which I responded, there
>had been such a finding by formal proceedings at Cornell University.

....various other bits of evidence deleted.

The issue here is whether it was appropriate to say that Mr. Morris
had released the worm prior to a finding of that fact in a court of
law.  IMHO it is not, and that we should say that this act is alleged,
until the court decides otherwise (which it recently did).

According to what you read in the papers, Mr. Morris's lawyers
conceded that he conducted the act of releasing the worm.  However,
this does not constitute a finding of fact, as you maintain.  I can
think of a half dozen instances where a confession to an act would be
rejected by a court of law after a weighting of ALL the evidence.  A
confession is merely evidence in a trial, and although it obviously
carries a great deal of weight, it does not, in and of itself,
constitute a finding of fact.

It was interesting to note how you structured your response to my
concern.  You listed the reasons why you felt that Mr. Morris's
releasing the worm was a "finding of fact", and not alleged.  In
effect, you conducted your own little mini-trial; using such evidence
as something you read in the New York Times.  Are you claiming that
you have heard ALL the evidence presented in this trial?  Are you
claiming to have been declared by both the prosecution and the defense
to be acceptable to sit in judgment in this case?  Do you have the
benefit of eleven other jurors to confer with and have agree with you
in your personal "finding of facts"?  No.  That is why we have courts
of law to find fact after weighting ALL the evidence as part of an
orderly process that protects all concerned (at least in theory).  I
do not want to assign this authority to the New York Times, nor the
Judicial Boards at Cornell, nor to your or my own personal evaluation
based on partial evidence.  Until the time that the court completed
its job and ruled on facts and guilt, I felt it was appropriate to
label the charges against Mr. Morris as alleged.

- ---------------------
John L. Cofer
[e-mail]
- ---------------------
All disclaimers apply

------------------------------

Date:    Tue, 30 Jan 90 08:21:20 +0700
From:    Chuck Martin <[e-mail]>
Subject: Public PC lab responsibility

What is a public lab responsibility to end users in regard to viruses?
The answer is that you do the best you can.

Our office Mac is available to the public for (emergency) laser
printing, and we have adopted measures to prevent infection.  First,
the user's disk is scanned for viruses with Disinfectant.  There are
absolutely *NO* exceptions.  If a virus is found, we offer to remove
it.  If that is declined, the user may receive Disinfectant 1.5 (free,
of course), to clean up his/her system.  Either way, we will *NOT*
have anything to do with an infected disk.

Some secondary protection measures include:
(1) all commands are issued by our staff, not the end user.
(2) Our hard drive is periodically scanned for infection.
(3) Vaccine is the first init installed.

I cannot say what our legal liability is, but surely any court can see that
we are taking all reasonable precautions.  Comments?

-
 -------------------------------------------------------------------------------
                           Chuck Martin, Consultant
            Computer Information Center, Washington State University
       MARTINCH @ WSUVM1.BITNET                      [phone]
-
 -------------------------------------------------------------------------------
       May you live in interesting times. - ancient Chinese curse/benison
-
 -------------------------------------------------------------------------------

------------------------------

Date:    30 Jan 90 18:39:47 +0000
From:    [e-mail] (Robert I. Eachus)
Subject: Re: Virus request

woodb!scsmo1![e-mail] writes:

> Should it be illegal to own or transmit virus source (for
non-security > personnel)??

     No, No, No, a thousand times NO!  If nothing else the discussion
in this group about the theoretical impossibility of determining
whether or not certain code is a virus should convince you that it is
certainly immpossible in practice as well as in theory whether any
source code could be intended as part of a virus.

     Also note that the Internet Worm could an did transmit and
compile source code on the machine it was infecting.  Should anyone
whose machine was infected be locked up?

     As a (part-time) system administrator, I think it is my
responsibility to track activity in this area.  If new virus threatens
any system for which I am responsible, I want to know that either I,
or someone I trust who specializes in virus detection and elimination,
can get a copy of the virus from someone who has been hit and
disassemble it.  It would be silly to say that I can be infected
(tough luck, sorry about that) but if I try to disassemble the virus I
am breaking the law.  Note that there are several "non-boot block"
viruses which imbed themselves in other programs.  The easiest way to
find them (before a special tool is developed for the particular
virus) is to use a disassembler.

>  Also, should there be an international watchdog agency set up to
>  investigate such requests??  Should the CIA/FBI/FCC be involved in
>  cooperation with IBM/DEC/AT&T/etc.. to form a task force along with
>  our list's virus expert?

   I think that sending something to this list is probably sufficient
notice to all of the existing watchdog groups.  I'll let Gene Spafford
answer whether the group set up in response to the Internet Worm is
interested in tracking such requests.

>   Has anyone contacted this person's administration along with MAINE's
>   and BITNIC/BITNET administration?

   I don't know.  I'm seeing this second hand, did you report it?

>  Right now, its up to us to report these requests and its the
>  responsibility of MAINE to act on requests submitted via UMNEWS.

   Agreed.  The current state of computer networking is true anarchy.
That means that we are all resonsible for our own protection.  (I
don't consider that a bad thing, but note that in any case nodes and
subnets may have rules and organizations to enforce them.  It is just
at the highest level that anarchy exists.)

>   Can we make it illegal to have virus sources without stomping on our
>   constitutional rights??  What about other countries??

   No.  Obviously there are some countries where such laws would be
constitutional.  However, like gun control any such regulations would
be futile, even if such laws could be enforced in a transnational
environment like the net.  If Robert Morris, Jr. had developed his
code (from New York State) on an computer in Canada, and relased it
into a European network, I think that he still might have violated the
(US) federal computer abuse statues, but where would he have violated
your proposed law against owning virus sources?

                                        Robert I. Eachus

with STANDARD_DISCLAIMER;
use  STANDARD_DISCLAIMER;
function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...

------------------------------

Date:    30 Jan 90 17:24:46 +0000
From:    [e-mail] (Ray Dunn)
Subject: Anti-virus suite

Please excuse if this is regularly published information....

Which among the many commercial and PD anti-virus programs would you
recommend as part of a cost-almost-no-object suite of programs to
protect an MSDos and OS/2 software development department against a
virus appearing on the development machines, or, infinitely worse, on
the product disk?

Does anyone offer a continuing anti-viral update service?

If you had to *guarantee* that no such product disks contained a
virus, how would you go about it, other than taking measures to
maintain an anti-infection clean-machine environment?

Thanks.  I'll summarize email replies back to this group.
- --
Ray Dunn.                    | UUCP: [e-mail]
Philips Electronics Ltd.     |       ..!{uunet|philapd|philabs}!philmtl!ray
600 Dr Frederik Philips Blvd | TEL : [phone]  Ext : 2347 (Phonemail)
St Laurent. Quebec.  H4M 2S9 | FAX : [phone]  TLX : 05-824090

------------------------------

Date:    30 Jan 90 19:06:43 +0000
From:    [e-mail] (Robert I. Eachus)
Subject: Re: Signature Programs

utoday![e-mail] (Ross M. Greenberg) writes:

    [e-mail] (Bob Bosen) writes:

   >1- The PERCENTAGE of the file that is subjected to the sophisticated
   >algorithm. This can sometimes be quite a small fraction of the whole
   >file.  (The remainder of the file can be processed by an industry-
   >standard CRC algorithm. There are various techniques deriving from
   >cryptology that can be used to cause the effects of the sophisticated
   >algorithms to "ripple through" all the way to the final signature.)
   >Properly implemented, these techniques can result in a reliable,
   >virtually unforgeable signature that is calculated almost as quickly as a
   >conventional CRC.

   True, only if you're looking for a known pattern.  Otherwise, you're
   guessing that your algorithm is smarter than the bad guys.  Not on my
   machine you don't!  You're gonna have to scan the whole file, every
   byte to tell me if there has been a change...[Lots more deleted.]

   What Bob Bosen is proposing is an algorithm which does scan the
whole file, and does notice if any byte has been changed.  His point
is that most of this checking can be done with simple CRC techniques
and only a small part of the file needs to be encrypted with a
sophisticated algorithm.  There exist such techniques, and if they are
correctly implemented the effort to change the program in a way hich
does not change the "final" CRC, or to calculate a new CRC result, is
at least as difficult as solving the sophisticated algorithm.

   Even in your "hypothetical" PC/XT case,the computer can perform
several instructions per each byte read from a hard disk.  It is
possible (and on my Amiga, I do exactly this) to use a packing
program, and a loader which automatically unpacks the executable code,
and have the packed code load quicker (from a fast hard disk even!)
than the actual program.  Saves on disk space too.  A packing program
which encoded source with my personal "signature" could produce pakced
programs which loaded faster (including the verification) than the
original program.  And if done "right" the encryption key needed to
create a loadable program could not be deduced from the loader.
(Unless P=NP :-)

                                        Robert I. Eachus

with STANDARD_DISCLAIMER;
use  STANDARD_DISCLAIMER;
function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Wednesday, 31 Jan 1990    Volume 3 : Issue 27

Today's Topics:

re: Universal virus detectors
WDEF A at Connecticut College (Mac)
Re: Thermal Nuclear War ?
4096 and 1260 Viruses (PC)
PC Magazine Free Utility: PCDATA (PC)
re: 1260 virus (PC)
Re: ADAPSO Virus Book
Disinfectant 1.6 (Mac)
Possible new virus?? Followup
Gatekeeper veto: Normal behavior or virus attack? (Mac)
WDEF A at Univ of Miami (PC)
virus propogation in non-executable files
The Checksum feature of FLU_SHOT+ (PC)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

---------------------------------------------------------------------------

Date:    30 Jan 90 00:00:00 +0000
From:    "David.M..Chess" <[e-mail]>
Subject: re: Universal virus detectors

I don't entirely understand the proposal from Jerry Leichter.  He
describes a system which (if I'm reading it right) basically allows
the user to get a known-correct "last written" timestamp for any
executable object.  It's not clear to me how this constitutes a
universal virus detector, though.  Don't we also need an algorithm
that looks at timestamps and timestamp-change histories, and detects
viruses on that basis?  That strikes me as a Hard Problem.  Does the
user review his timestamps once a day, and try to figure out which
changes are OK and which aren't?

Can the user really be counted on to get this right, given that virus
authors will shortly find out the detection methods that we're using,
and make viruses that act so as to be less likely to be noticed in
that environment (details left to the readers' own ingenuity...)?

Having a known-reliable "last changed" stamp for executables would be
very nice, and would help with the anti-virus effort.  I don't think
it quite makes it as a Universal Detector, though...

DC

------------------------------

Date:    Tue, 30 Jan 90 15:29:00 -0500
From:    [e-mail]
Subject: WDEF A at Connecticut College (Mac)

WDEF A has reared its head in our public labs and one office
AppleShare network.  Boy, does this thing spread like wildfire.

Gregg TeHennepe                        | Minicomputer Specialist
[e-mail]                  | Connecticut College, New London, CT

------------------------------

Date:    30 Jan 90 15:41:00 -0800
From:    [e-mail]
Subject: Re: Thermal Nuclear War ?

A suggestion might be for your friend to boot from a floppy and take a
look in his autoexec.bat file to insure that a batch file was not
created to type the message to his terminal BEFORE he reformat his
hard disk.  It really sounds as if someone might have created a small
"Welcome Home" batch file rather than a virus.  If the batch file does
not exist, then he/she can consider a total reformat.  All strange
messages are not necessarily viruses.

------------------------------

Date:    Tue, 30 Jan 90 15:32:57 -0800
From:    [e-mail]
Subject: 4096 and 1260 Viruses (PC)

This is a forward from John McAfee:
          A new breed of viruses has surfaced in the past two months.
These viruses are very complex and use sophisticated techniques to
avoid detection, identification and removal.  Since they are new
viruses, they are not yet widespread, but they are destined to become
major problems within the next year.  Among this new breed of viruses
is the 4096, Alabama, Virus-101 and the 1260.  Very little has been
written or discussed about these viruses, so I thought it was about
time to shed some light on a trend I'm sure we will see more of.
          The two most interesting of the new breed are the 4096 and the
1260 viruses.  The 4096 has had few public reports as yet, but this is
not surprising since it is virtually invisible - even if memory
resident filters like Flu-Shot+ or Protec are in use.  It is by far
the most sophisticated virus we have seen.  It is also the largest, as
measured by the number of instructions.  Numerous disassemblers have
copies of this virus, including Dave Chess, Joe Hirst, Morgan Schweers
and others, but we don't yet have a fully documented listing.  We do
know quite a bit however:
          The virus is memory resident and infects COMMAND.COM, EXE
files and COM files.  The virus initially places the machine in
single-step mode and then issues an interrupt 21, sub-function 52 to
determine the real address of the interrupt 21 code within DOS.
Thereafter, it issues a long jump to that location to avoid any
interrupt trapping antivirals that may be resident.  Thus the
infection process, after the virus becomes resident, is transparent.
          The strangest part of the virus is that it is also able to
trap all other disk reads and writes, and whenever an infected file is
accessed by any program, the virus performs a disinfection of the
program on the fly.  Thus checksumming techniques, file length checks,
and other file modification detectors cannot perceive the infection on
the disk.  Even searching the disk for the specific virus code will
fail, since the code is removed from the file during the read request.
Doing a directory of the disk likewise shows no virus effects.  The
real increased length of infected files is subtracted during the
directory listing.
          This characteristic has a surprising side effect: Whenever an
infected file is copied to another file that does not have an
executable extension, the new file turns out to be the original,
uninfected program.  Whenever this uninfected program is copied to any
other file that does have an executable extension, the end result is
an infected program again.
          We don't yet know the exact mechanisms used by this virus, but
we do know it works.  No memory resident virus filter, or system virus
scanner that we are aware of is able to prevent infection from this
virus, or detect an infection after it has occurred - providing that
the virus is active.  The only way, currently, that we know how to
detect this virus is to look for its code in memory.
          The 1260 virus, unlike the 4096, does not do much while active
in memory.  It does, however, have the most sophisticated encryption
technique yet used by a virus.  Not only is the virus fully encrypted,
but the code extractor is also garbled for each occurrence of the
virus.  This makes simple string matching useless for identification.
          There are eight working commands in the Code Extractor; the
remainder are fluff to allow that portion of code to look somewhat
different between implementations.  They are:
  1.   B8 nnnn    MOV AX,immediate
  2.   B9 nnnn    MOV CX,immediate
  3.   BF nnnn    MOV DI,immediate address = END+0028
  4.   31 0D      XOR W[DI],CX
  5.   31 05      XOR W[DI],AX
  6.   47         INC DI
  7.   40         INC AX
  8.   E2 nn      LOOP immediate address

------------------------------

Date:    Tue, 30 Jan 90 18:45:00 -0700
From:    Keith Petersen <[e-mail]>
Subject: PC Magazine Free Utility: PCDATA (PC)

All the programs in the PC Magazine PCDATA package are available
via anonymous ftp from SIMTEL20:

pd2:<msdos2.pcmag>
VOL9N03.ARC      188K  01-16-90  PCMag FASTRUN,MIRDIR,NOVIRUS,SCANSYS,XALL

- --Keith Petersen
Maintainer of SIMTEL20's CP/M, MSDOS, & MISC archives [IP address 26.2.0.74]
Internet: [e-mail], [e-mail]  BITNET: w8sdz@NDSUVM1
Uucp: {ames,decwrl,harvard,rutgers,ucbvax,uunet}!wsmr-simtel20.army.mil!w8sdz

------------------------------

Date:    30 Jan 90 21:17:00 +0100
From:    Morton Swimmer <[e-mail]>
Subject: re: 1260 virus (PC)

As a comment to what frisk mentioned about the 1260 virus, I would
like to add that, you likewise cannot tell the difference between the
Syslock, Macho and Advent viruses (viri?) using classical scan
methods. They all have identical startup code which will proceed to
decrypt the actual virus body. On top of that, Macho and Syslock have
identical lengths (and similar damage). Advent is however much
shorter.

I'm not a big fan of virus scanning anyway, but using checksums, as
I do, can be cumbersome.

Cheers, Morton

------------------------------

Date:    31 Jan 90 04:37:42 +0000
From:    [e-mail] (Gene Spafford)
Subject: Re: ADAPSO Virus Book

[e-mail] (Gene Spafford) writes:
>"Computer Viruses: Dealing with Electronic Vandalism and Programmed
>Threats" by Eugene Spafford, Kathleen Heaphy, and David Ferbrache.
>1989, 109 pages.  Published by ADAPSO.
[...]
>state and Federal laws against computer crime, and detailed
>descriptions of all IBM and Apple Macintosh viruses known as of 1
>October 1990.
         ^^^^

Geez, I'm still writing 1989 on my checks, and now I'm writing 1990
where I should be putting 1989!   Make that "known as of 1 October
1989" and realize you'll be old and forgetful someday too!
- --
Gene Spafford
NSF/Purdue/U of Florida  Software Engineering Research Center,
Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-2004
Internet:  [e-mail] uucp:     ...!{decwrl,gatech,ucbvax}!purdue!spaf

------------------------------

Date:    Wed, 31 Jan 90 00:03:21 -0500
From:    [e-mail]
Subject: Disinfectant 1.6 (Mac)

Disinfectant 1.6
================

January 30, 1990

Disinfectant 1.6 is a new release of our free Macintosh virus
detection and repair utility.

Version 1.6 automatically detects and repairs files infected by new
clones of the nVIR A and nVIR B viruses.  Several clones of nVIR B
have appeared, and in the past we had to configure and release a new
version of Disinfectant to properly recognize each new clone. This
should not be necessary in the future. The new generic nVIR clone
detection and repair algorithm is based on the one used by Steve
Brecher in his Repair program. Thanks to Steve for sharing his
code with us.

The new nVIR clone detection and repair feature was intended for
release as part of Disinfectant version 2.0, which is still being
developed.  Yet another clone of nVIR B was recently discovered at
Stanford University, so we decided to release just this part of
version 2.0 now.

Disinfectant 1.6 is available now via anonymous FTP from site
acns.nwu.edu [129.105.49.1].  It will also be available soon on
sumex-aim, rascal, comp.binaries.mac, CompuServe, Genie, Delphi, BIX,
MacNet, America Online, Calvacom, AppleLink, and other popular sources
for free and shareware software.

John Norstad
Academic Computing and Network Services
Northwestern University
2129 Sheridan Road
Evanston, IL 60208

Bitnet: jln@nuacc
Internet: [e-mail]
CompuServe: 76666,573
AppleLink: A0173

------------------------------

Date:    31 Jan 90 04:54:50 +0000
From:    munnari!dbrmelb.oz.au![e-mail] (Stephen Oakes)
Subject: Possible new virus?? Followup

Sincere apologies for the previous article I sent yesterday about a
possible new virus.  It turned out that it was a message installed as
a hoax by another party who altered the autoexec.bat file, and was not
in fact a virus.

PLease ignore my previous posting.

Thank you,
          Stephen Oakes,   [e-mail]

------------------------------

Date:    31 Jan 90 10:56:41 +0000
From:    [e-mail] (Norman Swenson)
Subject: Gatekeeper veto: Normal behavior or virus attack? (Mac)

I have noticed something suspiciously virus-like on my Mac II.  I was
getting a "Serious disk error" message from Microsoft Word and garbage
in my files when using the editor in TeXtures.  Fearing an imminent
disk crash, I backed up my hard disk to another.  While the files were
copying over. I got a veto message from Gatekeeper (ver 1.1.1, w
Gatekeeper Aid).  I decided to check my disk using Disinfectant 1.5
and found that Drawover (part of Adobe Illustrator) was infected with
nVir B.  I disinfected that file, and all my disks then scanned clean.
However, whenever I try to open the Illustrator folder on the backup
disk, I get the following veto message: 'Gatekeeper has vetoed an
attempt by Finder to violate "Res(other)" privileges against Desktop.
[AddResource(ADBS,0)]'.  I have isolated the behavior to the Adobe
Separator 2.0 program.  When I remove it from that folder, I do not
get the message.  When I put it back, I don't get the message the
first time I open the folder, but I do every time after that.  I made
a copy of the folder on another disk, and at first I got the same
behavior, but after I rebooted it went away on the second disk.  I
looked at both desktop files using resedit; one had the ADBS resource
in it, the other did not.  Is this normal behavior, or could it be due
to a virus that Disinfectant 1.5 is not catching?  Why would opening a
folder require adding a resource to the desktop file?  And why did
Gatekeeper veto it on one disk, but not the other?

Any information is greatly appreciated.

Norm
[e-mail]

------------------------------

Date:    Tue, 30 Jan 90 23:12:51 -0500
From:    [e-mail]
Subject: WDEF A at Univ of Miami (PC)

For tracking purposes, let me say that WDEF A has managed to reach the
Deep South...and has struck our public labs here on campus.

Yippee.

- --
Jason Gross     Comp Sci Ugrad     University of Miami     Class of '91 (?)
===========================================================================
Hey, wanna save the world? | Got sumtin' to say?        [e-mail]
Nuke a Godless, Communist, | Pick and choose!        [e-mail]
gay whale for Christ.      |                      [e-mail]
              - Anonymous  |
===========================================================================
          Lie: The University of Miami is a non-profit institution.

------------------------------

Date:    31 Jan 90 09:42:00 -0500
From:    "WARTHMAN" <[e-mail]>
Subject: virus propogation in non-executable files

In VIRUS-L Digest V3 #23,     [e-mail] writes:

> On another matter, there is a simple procedure which can be used to
> check for most viruses and other forms of corrupt code.  It is this:
> All viruses have to be in some executable file in order to act.
> ...
> Text files cannot
> propagate a virus and should not be deleted unless they have already
> been trashed by the corrupt code.

Although this may be the case in the MS-DOS and UNIX worlds, it is not
strictly the case in for the Macintosh. Certainly a virus must be
executed in order to spread, but that doesn't always mean that it must
attach to an "executable" file. In particular, the WDEF virus inserts
an executable resource into the "desktop" file. This file would never
ordinarily contain any executable code, just data which describes the
visual appearance of the disk volume on the Mac screen. Due to a
"feature" of the Mac operating system, however, an executable resource
can be contained in ordinary" data files and, under certain
circumstances, be executed. Thus, we have a situation in which data
files are used to contain and to propogate a virus. This is an
especially sneaky method, since the *program* that is running when
WDEF does its thing (Finder) is not, itsself, infected.

- -- Jim Warthman

------------------------------

Date:    Wed, 31 Jan 90 16:37:20 +0200
From:    Y. Radai <[e-mail]>
Subject: The Checksum feature of FLU_SHOT+ (PC)

  As happens every once in a while, I've fallen several weeks behind
in reading VIRUS-L (due to e-mail problems among other things), so
forgive me if I only now get around to replying to Ross Greenberg's
posting in Issue 5.

  Concerning his FSP (FLU_SHOT+) program Ross writes:
>                       However, to date, it seems to be good enough:
>no virus infection on a checksummed program has gotten through (to my
>users knowledge, naturally) without detection. I can only assume that
>lack of reporting can be equated to lack of infection

I'm willing to accept the assumption that no program checksummed by
FSP has ever been infected by an actual virus without FSP's detecting
it.  What I don't accept is that this shows that FSP is "good enough".
The assumption could equally well be true because users of FSP simply
don't bother using its checksum feature!!  In my opinion, the latter
explanation is far closer to the truth.
  Of the three people I know who use FSP, two checksum only the 3
files in the sample FLUSHOT.DAT file: COMMAND.COM and the 2 hidden
system files, and the other user doesn't use the checksumming feature
at all.  Why?  Because it's so extremely tedious to use.  The user is
forced to individually enter into his FLUSHOT.DAT file the name of
each file which he wishes to be checksummed along with a dummy check-
sum, to run the program, to copy down each checksum displayed by the
program, and then to manually replace each dummy checksum in
FLUSHOT.DAT by the correct value.  Since it's difficult for me to ima-
gine anyone going through all that bother on more than a few files, I
think my 3-user sample is representative.
  I might understand if the probability of these three files getting
infected were much greater than that of other files.  But precisely
the opposite is true.  There are only a few viruses which can infect
COMMAND.COM, and all of these (except possibly one) are relatively
rare.  And I haven't heard of a single virus which can infect either
of the other two files.  So the fact that no program checksummed by
FSP has been infected by a virus without being detected doesn't prove
very much about how good FSP's checker is.

>>How many of its users have the slightest idea how its security com-
>>pares with that of other programs?
>
>The users have to trust the program author of any security product.  As
>such, they have to trust that, if a virus were to infect files with a
>"zero differential" on the checksumming method I use, that I'd change
>the checksuming method.  Yes, there has to be a trust in your vendor.

My question had nothing to do with trust.  One may be very trustworthy
but still unknowingly distribute an inferior product.

>>     for any given file all users will get the same checksum, and
>>that's a potential security hole ....   But since this hole can
>>be plugged very simply and at no cost in speed, why not do so, Ross?
>
>             If they ask me: "Is my COMMAND.COM file infected?", I need
>simply ask them what the checksum is.  From that I know the answer.  If
>I used some method to generate unique checksums for each user, I'd still
>have to have some means to get back to the "real" checksum.

Sorry, but I don't understand why you have to get back to the "real"
checksum.  Suppose we improve the security by making the checksums
different for each user.  From the fact that some user's checksum has
changed relative to *whatever* it was when that user set up his
checksum base, we'd know precisely the same thing that you know by
comparing with the "real" checksum, namely that his file had been
altered (which *may* indicate infection).  So what do you gain by use
of the "real" checksum?
  But let's suppose you can show me that there's some purpose for
using real checksums.  Do I understand you correctly that you keep a
list of the real checksums of the COMMAND.COM file of all versions of
PC-DOS and MS-DOS which ever existed?  Then what about all the tens of
thousands of other files which might get infected and which your users
might ask you about?

>Please understand that I certainly can appreciate the limitations of using
>a less sophisticated algorithm within my code as versus something wonderfully
>complex.  But, as with any security product, I had to weigh off security
>versus convienience considerations.

Adding a random key to a simple algorithm wouldn't make it "wonderful-
ly complex" or less convenient in the slightest.

                                     Y. Radai
                                     Hebrew Univ. of Jerusalem, Israel
                                     [e-mail]

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Wednesday, 31 Jan 1990    Volume 3 : Issue 28

Today's Topics:

Introduction to the anti-viral archives
Amiga anti-viral archive sites
Apple II anti-viral archive sites
Atari ST anti-viral archive sites
Documentation anti-viral archive sites
IBMPC anti-viral archive sites
Macintosh anti-viral archive sites
UNIX anti-viral archive sites

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

---------------------------------------------------------------------------

Date:    31 Jan 90 05:26:06 +0000
From:    [e-mail] (Jim Wright)
Subject: Introduction to the anti-viral archives

# Introduction to the Anti-viral archives...
# Listing of 31 January 1990

This posting is the introduction to the "official" anti-viral archives
of VIRUS-L/comp.virus.  With the generous cooperation of many sites
throughout the world, we are attempting to make available to all
the most recent news and programs for dealing with the virus problem.
Currently we have sites for Amiga, Apple II, Atari ST, IBMPC, Macintosh
and Unix computers, as well as sites carrying research papers and
reports of general interest.

If you have general questions regarding the archives, you can send
them to this list or to me.  I'll do my best to help.  If you have a
submission for the archives, you can send it to me or to one of the
persons in charge of the relevant sites.

If you have any corrections to the lists, please let me know.

The files contained on the participating archive sites are provided freely
on an as-is basis.

To the best of our knowledge, all files contained in the archives are either
Public Domain, Freely Redistributable, or Shareware.  If you know of one
that is not, please drop us a line and let us know.  Reports of corrupt
files are also welcome.

PLEASE NOTE
The Managers of these systems, and the Maintainers of the archives, CAN NOT
and DO NOT guarantee any of these applications for any purpose.  All possible
precautions have been taken to assure you of a safe repository of useful
tools.

Jim Wright
[e-mail]

[Ed. Thanks again for a great volunteer effort, Jim!]

------------------------------

Date:    31 Jan 90 05:29:30 +0000
From:    [e-mail] (Jim Wright)
Subject: Amiga anti-viral archive sites


# Anti-viral archive sites for the Amiga
# Listing last changed 30 September 1989

cs.hw.ac.uk
          Dave Ferbrache <[e-mail]>
          NIFTP from JANET sites, login as "guest".
          Electronic mail to <[e-mail]>.
          Main access is through mail server.
          The master index for the virus archives can be retrieved as
                    request: virus
                    topic: index
          The Amiga index for the virus archives can be retrieved as
                    request: amiga
                    topic: index
          For further details send a message with the text
                    help
          The administrative address is <[e-mail]>

ms.uky.edu
          Sean Casey <[e-mail]>
          Access is through anonymous ftp.
          The Amiga anti-viral archives can be found in /pub/amiga/Antivirus.
          The IP address is 128.163.128.6.

uk.ac.lancs.pdsoft
          Steve Jenkins <[e-mail]>
          Service for UK only; no access from BITNET/Internet/UUCP
          Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft"
          FTP       : call lancs.pdsoft, user "pdsoft", pwd "pdsoft".
          Pull the file "help/basics" for starter info, "micros/index" for inde
\cx.
          Anti-Viral stuff is held as part of larger micro software collection
          and is not collected into a distinct area.

uxe.cso.uiuc.edu
          Mark Zinzow <[e-mail]>
          Lionel Hummel <[e-mail]>
          The archives are in /amiga/virus.
          There is also a lot of stuff to be found in the Fish collection.
          The IP address is 128.174.5.54.
          Another possible source is uihub.cs.uiuc.edu at 128.174.252.27.
          Check there in /pub/amiga/virus.

- --
Jim Wright
[e-mail]

------------------------------

Date:    31 Jan 90 05:29:55 +0000
From:    [e-mail] (Jim Wright)
Subject: Apple II anti-viral archive sites


# Anti-viral archive sites for the Apple II
# Listing last changed 30 September 1989

brownvm.bitnet
          Chris Chung <[e-mail]>
          Access is through LISTSERV, using SEND, TELL and MAIL commands.
          Files are stored as
                    apple2-l xx-xxxxx
          where the x's are the file number.

cs.hw.ac.uk
          Dave Ferbrache <[e-mail]>
          NIFTP from JANET sites, login as "guest".
          Electronic mail to <[e-mail]>.
          Main access is through mail server.
          The master index for the virus archives can be retrieved as
                    request: virus
                    topic: index
          The Apple II index for the virus archives can be retrieved as
                    request: apple
                    topic: index
          For further details send a message with the text
                    help
          The administrative address is <[e-mail]>

uk.ac.lancs.pdsoft
          Steve Jenkins <[e-mail]>
          Service for UK only; no access from BITNET/Internet/UUCP
          Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft"
          FTP       : call lancs.pdsoft, user "pdsoft", pwd "pdsoft".
          Pull the file "help/basics" for starter info, "micros/index" for inde
\cx.
          Anti-Viral stuff is held as part of larger micro software collection
          and is not collected into a distinct area.

- --
Jim Wright
[e-mail]


------------------------------

Date:    31 Jan 90 05:30:20 +0000
From:    [e-mail] (Jim Wright)
Subject: Atari ST anti-viral archive sites


# Anti-viral archive sites for the Atari ST
# Listing last changed 30 September 1989

cs.hw.ac.uk
          Dave Ferbrache <[e-mail]>
          NIFTP from JANET sites, login as "guest".
          Electronic mail to <[e-mail]>.
          Main access is through mail server.
          The master index for the virus archives can be retrieved as
                    request: virus
                    topic: index
          The Atari ST index for the virus archives can be retrieved as
                    request: atari
                    topic: index
          For further details send a message with the text
                    help
          The administrative address is <[e-mail]>.

panarthea.ebay
          Steve Grimm <[e-mail]>
          Access to the archives is through mail server.
          For instructions on the archiver server, send
                    help
          to <[e-mail]>.

uk.ac.lancs.pdsoft
          Steve Jenkins <[e-mail]>
          Service for UK only; no access from BITNET/Internet/UUCP
          Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft"
          FTP       : call lancs.pdsoft, user "pdsoft", pwd "pdsoft".
          Pull the file "help/basics" for starter info, "micros/index" for inde
\cx.
          Anti-Viral stuff is held as part of larger micro software collection
          and is not collected into a distinct area.

- --
Jim Wright
[e-mail]


------------------------------

Date:    31 Jan 90 05:30:48 +0000
From:    [e-mail] (Jim Wright)
Subject: Documentation anti-viral archive sites


# Anti-viral archive sites for documentation
# Listing last changed 30 January 1990

cert.sei.cmu.edu
          Kenneth R. van Wyk <[e-mail]>
          Access is available via anonymous ftp, IP number 128.237.253.5.
          This site maintains archives of all VIRUS-L digests, all
          CERT advisories, as well as a number of informational documents.
          VIRUS-L/comp.virus information is in:
                    ~ftp/pub/virus-l/archives
                    ~ftp/pub/virus-l/archives/predigest
                    ~ftp/pub/virus-l/archives/1988
                    ~ftp/pub/virus-l/archives/1989
                    ~ftp/pub/virus-l/docs
          CERT advisories are in:
                    ~ftp/pub/cert_advisories

csrc.ncsl.nist.gov
          John Wack <[e-mail]>
          This site is available via anonymous ftp, IP number 129.6.48.87.
          The archives contain all security bulletins issued thus far from
          organizations such as NIST, CERT, NASA-SPAN, DDN, and LLNL-CIAC.
          Also, other related security publications (from NIST and others)
          and a partial archive of VIRUS_L's and RISK forums.

cs.hw.ac.uk
          Dave Ferbrache <[e-mail]>
          NIFTP from JANET sites, login as "guest".
          Electronic mail to <[e-mail]>.
          Main access is through mail server.
          The master index for the virus archives can be retrieved as
                    request: virus
                    topic: index
          The index for the **GENERAL** virus archives can be retrieved as
                    request: general
                    topic: index
          The index for the **MISC.** virus archives can be retrieved as
                    request: misc
                    topic: index
          **VIRUS-L** entries are stored in monthly and weekly digest form from
          May 1988 to December 1988.  These are accessed as log.8804 where
          the topic substring is comprised of the year, month and a week
          letter.  The topics are:
                    8804, 8805, 8806 - monthly digests up to June 1988
                    8806a, 8806b, 8806c, 8806d, 8807a .. 8812d - weekly digests
          The following daily digest format started on Wed 9 Nov 1988.  Digests
          are stored by volume number, e.g.
                    request: virus
                    topic: v1.2
          would retrieve issue 2 of volume 1, in addition v1.index, v2.index an
\cd
          v1.contents, v2.contents will retrieve an index of available digests
          and a extracted list of the the contents of each volume respectively.
          **COMP.RISKS** archives from v7.96 are available on line as:
                    request: comp.risks
                    topic: v7.96
          where topic is the issue number, as above v7.index, v8.index and
          v7.contents and v8.contents will retrieve indexes and contents lists.
          For further details send a message with the text
                    help
          The administrative address is <[e-mail]>

lehiibm1.bitnet
          Ken van Wyk <[e-mail]> new: <[e-mail]>
          This site has archives of VIRUS-L, and many papers of
          general interest.
          Access is through ftp, IP address 128.180.2.1.
          The directories of interest are VIRUS-L and VIRUS-P.

uk.ac.lancs.pdsoft
          Steve Jenkins <[e-mail]>
          Service for UK only; no access from BITNET/Internet/UUCP
          Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft"
          FTP       : call lancs.pdsoft, user "pdsoft", pwd "pdsoft".
          Pull the file "help/basics" for starter info, "micros/index" for inde
\cx.
          Anti-Viral stuff is held as part of larger micro software collection
          and is not collected into a distinct area.

unma.unm.edu
          Dave Grisham <[e-mail]>
          This site has a collection of ethics documents.
          Included are legislation from several states and policies
          from many institutions.
          Access is through ftp, IP address 129.24.8.1.
          Look in the directory /ethics.

- --
Jim Wright
[e-mail]


------------------------------

Date:    31 Jan 90 05:31:12 +0000
From:    [e-mail] (Jim Wright)
Subject: IBMPC anti-viral archive sites


# Anti-viral archive for the IBMPC
# Listing last changed 16 December 1989

cs.hw.ac.uk
          Dave Ferbrache <[e-mail]>
          NIFTP from JANET sites, login as "guest".
          Electronic mail to <[e-mail]>.
          Main access is through mail server.
          The master index for the virus archives can be retrieved as
                    request: virus
                    topic: index
          The IBMPC index for the virus archives can be retrieved as
                    request: ibmpc
                    topic: index
          For further details send a message with the text
                    help
          The administrative address is <[e-mail]>

f.ms.uky.edu
          Daniel Chaney <[e-mail]>
          This site can be reached through anonymous ftp.
          The IBMPC anti-viral archives can be found in /pub/msdos/AntiVirus.
          The IP address is 128.163.128.6.

mibsrv.mib.eng.ua.edu
          James Ford <[e-mail]> <[e-mail]>
          This site can be reached through anonymous ftp.
          The IBM-PC anti-virals can be found in PUB/IBM-ANTIVIRUS
          Uploads to PUB/IBM-ANTIVIRUS/00UPLOADS.  Uploads are screened.
          Requests to [e-mail] for UUENCODED files will be filled
          on a limited bases as time permits.
          The IP address is 130.160.20.80.

uk.ac.lancs.pdsoft
          Steve Jenkins <[e-mail]>
          Service for UK only; no access from BITNET/Internet/UUCP
          Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft"
          FTP       : call lancs.pdsoft, user "pdsoft", pwd "pdsoft".
          Pull the file "help/basics" for starter info, "micros/index" for inde
\cx.
          Anti-Viral stuff is held as part of larger micro software collection
          and is not collected into a distinct area.

uxe.cso.uiuc.edu
          Mark Zinzow <[e-mail]>
          This site can be reached through anonymous ftp.
          The IBMPC anti-viral archives are in /pc/virus.
          The IP address is 128.174.5.54.

vega.hut.fi
          Timo Kiravuo <[e-mail]>
          This site (in Finland) can be reached through anonymous ftp.
          The IBMPC anti-viral archives are in /pub/pc/virus.
          The IP address is 130.233.200.42.

wsmr-simtel20.army.mil
          Keith Peterson <[e-mail]>
          Direct access is through anonymous ftp, IP 26.2.0.74.
          The anti-viral archives are in PD1:<MSDOS.TROJAN-PRO>.
          Simtel is a TOPS-20 machine, and as such you should use
          "tenex" mode and not "binary" mode to retreive archives.
          Please get the file 00-INDEX.TXT using "ascii" mode and
          review it offline.
          NOTE:
          There are also a number of servers which provide access
          to the archives at simtel.
          WSMR-SIMTEL20.Army.Mil can be accessed using LISTSERV commands
          from BITNET via LISTSERV@NDSUVM1, LISTSERV@RPIECS and in Europe
          from EARN TRICKLE servers.  Send commands to TRICKLE@<host-name>
          (for example: TRICKLE@AWIWUW11).  The following TRICKLE servers
          are presently available: AWIWUW11 (Austria), BANUFS11 (Belgium),
          DKTC11 (Denmark), DB0FUB11 (Germany), IMIPOLI (Italy),
          EB0UB011 (Spain) and TREARN (Turkey).

- --
Jim Wright
[e-mail]


------------------------------

Date:    31 Jan 90 05:31:47 +0000
From:    [e-mail] (Jim Wright)
Subject: Macintosh anti-viral archive sites


# Anti-viral archive sites for the Macintosh
# Listing last changed 07 November 1989

cs.hw.ac.uk
          Dave Ferbrache <[e-mail]>
          NIFTP from JANET sites, login as "guest".
          Electronic mail to <[e-mail]>.
          Main access is through mail server.
          The master index for the virus archives can be retrieved as
                    request: virus
                    topic: index
          The Mac index for the virus archives can be retrieved as
                    request: mac
                    topic: index
          For further details send a message with the text
                    help
          The administrative address is <[e-mail]>

ifi.ethz.ch
          Danny Schwendener <[e-mail]>
          Interactive access through DECnet (SPAN/HEPnet):
                    $SET HOST 57434  or $SET HOST AEOLUS
                    Username: MAC
          Interactive access through X.25 (022847911065) or Modem 2400 bps
          ([phone]):
                    # CALL B050 <cr><cr>
                    Username: MAC
          Files may also be copied via DECnet (SPAN/HEPnet) from
                    57434::DISK8:[MAC.TOP.LIBRARY.VIRUS]

rascal.ics.utexas.edu
          Werner Uhrig <[e-mail]>
          Access is through anonymous ftp, IP number is 128.83.144.1.
          Archives can be found in the directory mac/virus-tools.
          Please retrieve the file 00.INDEX and review it offline.
          Due to the size of the archive, online browsing is discouraged.

scfvm.bitnet
          Joe McMahon <[e-mail]>
          Access is via LISTSERV.
          SCFVM offers an "automatic update" service.  Send the message
                    AFD ADD VIRUSREM PACKAGE
          and you will receive updates as the archive is updated.
          You can also subscribe to automatic file update information with
                    FUI ADD VIRUSREM PACKAGE

sumex-aim.stanford.edu
          Bill Lipa <[e-mail]>
          Access is through anonymous ftp, IP number is 36.44.0.6.
          Archives can be found in /info-mac/virus.
          Administrative queries to <[e-mail]>.
          Submissions to <[e-mail]>.
          There are a number of sites which maintain shadow archives of
          the info-mac archives at sumex:
          * MACSERV@PUCC                services the Bitnet community
          * LISTSERV@RICE               for e-mail users
          * FILESERV@IRLEARN  for folks in Europe

uk.ac.lancs.pdsoft
          Steve Jenkins <[e-mail]>
          Service for UK only; no access from BITNET/Internet/UUCP
          Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft"
          FTP       : call lancs.pdsoft, user "pdsoft", pwd "pdsoft".
          Pull the file "help/basics" for starter info, "micros/index" for inde
\cx.
          Anti-Viral stuff is held as part of larger micro software collection
          and is not collected into a distinct area.

wsmr-simtel20.army.mil
          Robert Thum <[e-mail]>
          Access is through anonymous ftp, IP number 26.2.0.74.
          Archives can be found in PD3:<MACINTOSH.VIRUS>.
          Please get the file 00README.TXT and review it offline.

- --
Jim Wright
[e-mail]


------------------------------

Date:    31 Jan 90 05:32:15 +0000
From:    [e-mail] (Jim Wright)
Subject: UNIX anti-viral archive sites


# Anti-viral and security archive sites for Unix
# Listing last changed 30 September 1989

attctc
          Charles Boykin <[e-mail]>
          Accessible through UUCP.

cs.hw.ac.uk
          Dave Ferbrache <[e-mail]>
          NIFTP from JANET sites, login as "guest".
          Electronic mail to <[e-mail]>.
          Main access is through mail server.
          The master index for the virus archives can be retrieved as
                    request: virus
                    topic: index
          For further details send a message with the text
                    help
          The administrative address is <[e-mail]>

sauna.hut.fi
          Jyrki Kuoppala <[e-mail]>
          Accessible through anonymous ftp, IP number 128.214.3.119.
          (Note that this IP number is likely to change.)

ucf1vm
          Lois Buwalda <[e-mail]>
          Accessible through...

wuarchive.wustl.edu
          Chris Myers <[e-mail]>
          Accessible through anonymous ftp, IP number 128.252.135.4.
          A number of directories can be found in ~ftp/usenet/comp.virus/*.

- --
Jim Wright
[e-mail]


------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Wednesday,  3 Jan 1990    Volume 3 : Issue 3

Today's Topics:

Viruses in Public Labs (Mac)
gatekeeper (Mac)
re: Virus Trends
Virus data collection
(forwarded) review of The Cuckoo's Egg
Re: Spafford's Theorems
Two serious cases (PC)
Gatekeeper Aid Question (Mac)
SCANV54 (PC)
Re: WDEF / Apology to Mainstay Software (Mac)
Disinfecting Binhexed Files (mac)
New viruses (PC)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

---------------------------------------------------------------------------

Date:    Fri, 29 Dec 89 17:38:00 -0500
From:    [e-mail]
Subject: Viruses in Public Labs (Mac)

I work in a computer lab at the University of North Texas, and we have had
a *lot* of experience with Mac virus problems.

The lab is a public access facility, and anyone in the University can use
the Macs (Mac II, color, 2 meg ram, 40 meg HD).  We have a very diverse
collection of people who wander through, and most of them want to use their
own software.

Some observations:

WDEF has *not* made it here yet...

Almost every other kind has.  I think I have the current record for most
diversity in one machine:
        SCORES
        NVIRa
        NVIRb
        INIT 29
It crashed, and the user wanted to know what was wrong......

INIT 29 can cause a System death all by itself.

We have been running Disenfectant for several months, and it works great.
I noticed that one machine that was "clean" after Disinfectant 1.3 had
a "partially infected" System and Finder when checked with 1.5.

Another problem was that we run all eight Macs off of an IBM file server
under Netware, and that Netware allows infections to be written in by
a program (though it won't cross-infect on the server itself).

Gatekeeper does not like Ethernet boards... :(

Is anyone running or working on a "pre-emptive" anti-virus product like
SAM or Gatekeeper that will work well with Netware and Ethernet?  Please
let me know (if possible).

Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>Chad Irby               > "Bill?"                     >
>Somewhere in...         > "What?"                     >
>Denton, TX              > "Strange things are afoot   >
>[e-mail]   >   at the Circle K."         >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

------------------------------

Date:    Tue, 02 Jan 90 15:45:51 +0000
From:    [e-mail] (Mike Garrison)
Subject: gatekeeper (Mac)

as a new reader I have what is probably an oft repeated question:

is there an address to send to for info on gatekeeper, first aid, etc....
I would like to know how to order/obtain some of this software.


------------------------------

Date:    Tue, 02 Jan 90 11:54:19 -0500
From:    [e-mail]
Subject: re: Virus Trends

> 2. The press speculation about the DATACRIME virus was much more
> damaging than the virus.

I don't think so.  True, the general public was alarmed out of proportion
to the threat.  But I suspect the press coverage encouraged a lot of people
to back up machines that hadn't been backed up.  This is good because

> 1. The amount of damage to data and availability done by viruses to date
> has been less than users do to themselves by error every day.

is undoubtedly true, and those crashed hard disks have to be reloaded from
someplace.

Bill Cheswick
[e-mail]

------------------------------

Date:    Tue, 02 Jan 90 00:00:00 +0000
From:    "Dean E. Nelson" <[e-mail]>
Subject: Virus data collection

There has been some discussion in past digests about similarities
between biological and computer viruses. I guess that is where the name
came from.  There is one big difference, however.  Biological viruses
have been around for much longer.  This fact, in itself, is not very
useful, but because they have been around longer, there is a much
longer history of human response to them.

The initial human response to viruses was not scientific.  People got
ill and suffered.  They would blame themselves, family members, or
perhaps the stars for their mallady.  Often they would seek divine (or
supernatural) intervention.  I'm sure we can all think of users who
consider the action of their computers magic and viral attacks within
the same realm.

As science increased our understanding of the human body, viral
infections became better understood.  The medical profession became
more and more able to combat viral infection and even impute immunity
before an attack.  This was possible because of an understanding of the
causal chains associated with viruses.

By the very nature of computer viruses (they are programs), the causal
chains associated with them can be made much clearer in a much shorter
period of time than with biological viruses.  Therefore, the research
done to understand the computer virus is much faster and more complete
than with its biological counterpart.  The resulting interventions are
also more complete and failsafe than their biological counterparts.

Given all that, perhaps there are still techniques used to combat
biological viruses that haven't been used with computer viruses.  After
all, we have been at that much longer and against a more insidious foe.

After some thought, I can only think of things that rely on data
analysis.  Given the data, we could determine which prevention
techniques were most effective, and we could better understand the
effects of different interventions and the factors which aid or inhibit
spread of the infection.

I agree with Mr.  McMahon (vol 3.  issue 1) that data collection is a
good first step (in trying to minimize the *effect* of viruses) .  I
also believe that Mr.  Murray (same issue) makes a useful analogy when
he refers to the study of virus spread as an Epidemiological pursuit.
The preceding paragraphs were written to make that very same point.

Dean Nelson, Lehigh University Computing Center
[e-mail]    [e-mail]   [phone]

------------------------------

Date:    Tue, 02 Jan 90 14:28:05 -0500
From:    Kenneth R. van Wyk <[e-mail]>
Subject: (forwarded) review of The Cuckoo's Egg


Forwarded (with the author's permission) from misc.security:

Date: 8 Dec 89 22:22:52 GMT
From: [e-mail] (Evelyn C Leeper)
Subject: THE CUCKOO'S EGG by Clifford Stoll

                      THE CUCKOO'S EGG by Clifford Stoll
                 Doubleday, 1989, ISBN 0-385-24946-2, $19.95.
                      A book review by Evelyn C. Leeper

     If you're wondering what to get that computer-addict friend of yours
for Hannukah, or she's wondering what to get you, try Clifford Stoll's book
about tracking a West German spy through the UNIX* computer networks.  When
I got the book I decided to take a look at the first couple of chapters just
to see how it was, and found myself so hooked that I sat down and read it
straight through in one evening.

     Now perhaps I'm somewhat predisposed to this topic, being associated
with security in a professional capacity.  And since I am a science fiction
reader, the whole cyberpunk movement (or non-movement) has made me even more
aware of the possibilities for this sort of activity.  So I can't say that
you should run out and buy this book for your Uncle Fred, who has yet to
figure out how to make the clock stop blinking on his VCR.  But if you're at
all interested in the topic and somewhat knowledgeable about computers, or
willing to learn, you should have no trouble following the events described
in the book.  The groundwork and basic terminology are laid out and
explained.  In science fiction, this is usually accomplished by having the
girlfriend of the hero ask, "Gee, Fred, what is a computer anyway?" but
Stoll is able to avoid this, in part because he was not originally a
computer scientist and often needed terms and procedures clarified for
himself.

     In addition to having a fast-moving, hi-tech spy plot (is Stoll the Tom
Clancy of the computer set?), the book provides some insight into how
security REALLY works.  For those who worry about how much the government is
watching what they do, the truth will come as a great relief: it's next to
impossible to get the government to care about anything that goes on in and
around computers unless you can hit them over the end with the equivalent of
a ten-ton weight, and even then they may merely blink momentarily.  And
while most of the time, that pesky 75-cent accounting error isn't worth
tracking down, every once in a while you can hit the jackpot.

     A nice by-product of all this is that the book would not be a bad
supplemental text for a computer security course.  (Well, a nice by-product
for Stoll, anyway.)  One of the problems with the standard UNIX system
security texts is that they tell you how to make your system secure, but
don't tell you want to do when you somehow find yourself with a system
insecure enough that someone has broken in.  THE CUCKOO'S EGG shows you some
"tricks of the trade" that aren't spelled out elsewhere.  I find myself
wishing that all our computer users would read this book so they'd stop
asking why they need passwords or why permissions can't be freed up.  (I
occasionally describe the latter phenomenon by claiming that many users
think that "0777" is the only possible first argument for CHMOD.)

     The book closes with a epilogue recounting the Great Internet Virus of
November 1988.  (With my usual excellent planning I was 8000 miles away when
it all hit the fan and heard about it only in retrospect.)  While some may
question its place here--the virus, so far as anyone knows, had nothing to
do with the West German hacker--I think the epilogue may teach the most
important lesson of the book: your systems are never perfectly secure.
There will always be one more hole, one more back-door, one more weak point.
To paraphrase John Philpot Curran, "The condition upon which [one has secure
systems] is eternal vigilance."  And while more technical descriptions of
the virus are available "in the literature" (as they say), this is a good
explanation for the wider audience of this book.

     Some have said the book should be edited down, but I don't think the
personal asides (including the infamous chocolate-chip cookie recipe
everyone is talking about!) hurt the book, and they go a long way toward
filling in a picture of what Stoll is like.  (Actually, I saw him being
interviewed on C-SPAN, and as quirky as he is in the book, he's three times
more so on screen.)

     [Note: a more concise, and somewhat more technically oriented, of this
saga may be found in Stoll's article "Stalking the Wily Hacker" in the May
1988 COMMUNICATIONS OF THE ACM.

* UNIX is a registered trademark of AT&T.

Evelyn C. Leeper   |   [phone]   |   att!mtgzy!ecl or [e-mail]
Disclaimer: This review is solely my opinion and the opinions
expressed therein should not be attributed to my employer (or anyone
else, for that matter).

------------------------------

Date:    Tue, 02 Jan 90 11:02:44 -0500
From:    Brian Piersel <[e-mail]>
Subject: Re: Spafford's Theorems

On Fri, 22 Dec 89 12:28:00 -0500 <[e-mail]> said:
>6. The current vector for viruses is floppy disks and diskettes, not
>programs.  That is to say, it is the media, rather than the programs,
>that are moving and being shared.

What about infected programs uploaded to a BBS? If someone else downloads
that program and uses it, their system will be infected with the same virus.
In this case, the media has _not_ moved, which would indicate that programs
are also a vector for viruses.

Of course, in some cases, such as viruses that infect boot sectors, etc.,
the disk itself must be shared, but in others, it is only the program that
must move.

+----------------------------------------------+
|  Brian Piersel                               |
+----------------------------------------------+
| BITNET:  SPBK09@SDNET                        |
| INTERNET:  [e-mail] |
+----------------------------------------------+
| IBM = Itty Bitty Machine                     |
+----------------------------------------------+

------------------------------

Date:    Wed, 27 Dec 89 12:47:52 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Two serious cases (PC)

Most virus researchers exchange/distribute viruses only on a strict
need-to-know basis, in order to limit the spread of viruses. However, this
does not work as well as intended. There are now two known cases where
untrustworthy people seem to have obtained viruses from researchers.

Case #1: Icelandic-1/Saratoga

     I discovered the Icelandic-1 virus here in Iceland in June this year.
     When I had disassembled it, I sent a disassembly of an infected file
     to several experts in the USA, UK and Israel, including the HomeBase
     folks (McAfee). Before I sent out the disassembly, I made one small
     change to it. This change had no effect on the operation of the virus,
     but it would make it possible to determine if a copy of this virus found
     outside of Iceland was based on my disassembly or not.

     Looking back, I can see that this was not a very good idea, simply
     because there was a possibility that somebody might select an invalid
     identification string, based on this disassembly. So, those of you having
     a copy of my disassembly, please contact me if you want to correct it.
     This change was also (by accident) included in the Icelandic-2
     disassembly, since I used the Icelandic-1 disassembly as a basis for
     that.

     Now - back to the Icelandic-1 virus.

     Three days after the virus was made available on the HomeBase bulletin
     board, in a restricted area that only a few people had access to, a new
     virus was discovered in Saratoga and uploaded to the HomeBase BBS. Some
     people thought for a while that Saratoga was an older variant of
     Icelandic-1, because it was at first said to have been found "a few
     months earlier", but this turned out to be a misunderstanding.

     Saratoga was just a minor variant of Icelandic-1, but the change I made
     was present in the virus, so it was obviously based on my disassembly.
     When Saratoga was found, I had only sent Icelandic-1 to three or four
     persons in the US - and, as far a I know, it had only been made available
     to other persons in one place (HomeBase).  They believe that the person
     responsible for the creating "Saratoga" has now been found, and his
     access to the restricted area has been terminated.


Case #2: Dbase

     The dBase virus was discovered by Ross Greenberg. It seems to have been
     planted at only a single site, because no other reports appeared for
     several months. Recently Ross made the virus available to a number of
     virus researchers. Within two weeks the first infection reports had
     started to arrive - the virus had escaped.

     We know that at least some of the reported infections were based on the
     copy from Ross, because he made one small change to the virus, before it
     was distributed. One instruction was overwritten by two "harmless"
     instructions, in order to disable the most harmful effect of the virus -
     the disk trashing part. This change is also present in some of the
     infected files that have been found recently. (In other cases the
     original instruction is present)

As I said before, I do not consider it a very good idea to make changes to
viruses, but it paid off in the two cases described above. Who knows how
many other cases of virus infections are (indirectly) the result of virus
collection/distribution by virus experts.

At least it is certain that we have to be a lot more careful in the future.

- -frisk

------------------------------

Date:    02 Jan 90 21:04:29 +0000
From:    [e-mail] (Sean P. Nolan)
Subject: Gatekeeper Aid Question (Mac)

Hi ho...

I hope this hasn't been asked already --- I've been gone for the
holidays and just discovered the problem.

I read about WDEF A and B, and checked my system with Disinfectant
1.5. No virus of any type found. Since I use Gatekeeper, I then
decided to drop the Gatekeeper Aid INIT into my system folder. Again,
ok. Until, just yesterday, when I tried to Get Info on the Finder.
Click on the Finder, Get Info, and zap. Cursor freezes, various ugly
noises, etc etc. and then a reboot. I have a billion INITs running,
but narrowed it down to Gatekeeper Aid by pulling things in and out of
the system folder and rebooting.

The problem seems only to happen with the Finder, i.e. I can get info
on any other file, and I haven't found any other problems. Still, it's
a little disconcerting, so I thought I'd drop a note and see if people
know about the quirk, and if there's a fix.

Thanks!

- --- Sean

SE/20 with internal 20 meg and external Microtech Nova 40.
System 6.0.3
4 Megs RAM
Gatekeeper Aid
GateKeeper 1.1.1
Adobe Type Manager
Moire 3.0
Soundmaster 1.2
Remember 1.3
TappyType
Programmer's Key
Safe Eject
KSP (Dartmouth-specific comm. protocal INIT)
MacroMaker
Easy Access
AppleShare
Broadcast
Public Folder 1.0
Shield INIT (from SUM)

( I know that's a million of them, but I honestly have checked them
all and Gatekeeper Aid is the problem... I still have the problem even
running only GK Aid and GK.)

+----------------------------------------------------------------------------+
| Sean P. Nolan     | Net: [e-mail] |  "Let's face it:   |
| Dartmouth College |                                   |   IBM is no fun."  |
| Hinman Box 2658   |            SCALP 'EM!             |     ::::::::::     |
| Hanover, NH 03755 |                                   |   John C. Dvorak   |
+----------------------------------------------------------------------------+

------------------------------

Date:    Tue, 02 Jan 90 16:04:08 -0800
From:    [e-mail]
Subject: SCANV54 (PC)

       ViruScan versions V53 and V54 have been released in rapid succession.
V53 contains a bug which causes false positives for the 4096 virus on some
systems and V54 fixes the bug.  Both versions now detect the 4096, Oropax,
Chaos and Virus-90, bringing the total number of known and detected PC
viruses to 60.  Let's hope this explosion in the number of new viruses slows
down this year.
       V54 is available now on HomeBase - 408 988 4004.
Alan

------------------------------

Date:    Wed, 03 Jan 90 06:10:35 +0000
From:    biar![e-mail] (Robert J Woodhead)
Subject: Re: WDEF / Apology to Mainstay Software (Mac)

[e-mail] writes:

> 1st Aid Software deserves a great deal of credit for having the only
> virus prevention tool that was capable of catching WDEF.  Everybody
> else failed, including Symantec's SAM, HJC's Virex, Gatekeeper, and
> Vaccine.  I don't know about MainStay's AntiToxin - I don't have a
> copy of that either (yet).

Not _quite_ true, John.  The VIREX "Record/Scan" operation has been
scanning for WDEFs et all since it was added.  The problem is that it
takes longer than a normal scan, so most VIREX users don't bother with
it.  A Pity.  It and the 1st Aid tool are really good at pointing out
wierdnesses.

- --
Robert J Woodhead, Biar Games, Inc.   !uunet!biar!trebor | [e-mail]
Announcing TEMPORAL EXPRESS.  For only $999,999.95 (per page), your message
will be carefully stored, then sent back in time as soon as technologically
possible.  TEMEX - when it absolutely, postively has to be there yesterday!

------------------------------

Date:    Wed, 03 Jan 90 05:55:47 -0500
From:    Thomas Neudecker <[e-mail]>
Subject: Disinfecting Binhexed Files (mac)

I am trying to maintain a local Macintosh bboard [The Pittsburgh Apple
Business Users Group, [phone]].  The vast majority of the files
posted to the bboard have been Binhexed and or Stuffit.  Time does not
allow me to test each of the uploads submitted for posting on the
board.  But I donUt want to pass any viruses to those who download
files from my board.  I suspect that virus detection utilities will
just consider these files to be clean ASCII documents.  So running
Disinfectant to check and clean the bboards inbox is useless.  Does
anyone know of a tool that will read the files creator type and if it
is Binhex or Stuffit do the translation on the fly, disinfect, and
restore the file type?  A version for both the Macintosh OS and UNIX
would help slow the spread of viruses via bboards.

Tom Neudecker
Carnegie Mellon University
[e-mail]

------------------------------

Date:    Wed, 03 Jan 90 10:54:39 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: New viruses (PC)

Several new PC viruses have appeared recently. This short note
contains a preliminary description of some of them, including the new
viruses in the package from Poland.

I have updated my anti-virus programs to detect, stop and remove the
viruses listed below (as well as the other 40 PC viruses known), and
unless somebody sends me a new virus today, I will start sending the
programs out tomorrow or the day after that.

                                The Amstrad virus.

This virus is rather interesting. It is a direct-action virus, that
will add 847 bytes to the front of any .COM file it finds in the
current directory.  The virus is very primitive, because the virus
code is only around 334 bytes long, which makes this the shortest PC
virus known today. The rest contains zeros and the string:

        "Hello, John Mcafee,please uprade me.Bests regards,Jean Luz."

One note: I feel the name "Amstrad" is totally inappropriate, since
the virus seems to have nothing to do with Amstrad computers
whatsoever.

                                The Payday virus

This is not a new virus, just a YAVJV (Yet Another Variant of the Jerusalem
Virus). It seems to be very close (or perhaps identical) to Jerusalem-B.

                                Musician

One of the viruses from Poland. As reported earlier, it is the same virus as
the "Oropax" virus reported several months ago in W-Germany.

                        Perfume (alias 765 or "4711")

A .COM infecting virus of German origin, that will sometimes ask the
user a question and not run the infected file unless the answer is
"4711", which is the name of a perfume.  This virus will look for
COMMAND.COM and infect it unless it is already infected.  Infected
files grow by 765 bytes. In the most common variant of the virus, the
questions have been overwritten with garbage.

                                  W13

This is a rather primitive .COM infecting virus.  Two variants are
known, the first one is 534 bytes long, but the second (with some bugs
corrected) is only 507 bytes long.  The virus is of the "Direct
Action" type does nothing interesting.

                                Vcomm

An .EXE infecting virus that came from Poland.  It is not very well
written, but easy to study, since the commented source code was
included.  When an infected program is run, it will infect one .EXE
file in the current directory.  Infected programs are first padded so
their length becomes a multiple of 512 bytes.  Then the virus adds 637
bytes to the end of the file.  It will also install a resident part
that will intercept any disk write and change it into a disk read.

                            December 24th

An Icelandic variant of the Icelandic-2 virus. It will infect one out
of every ten .EXE files run. Infected files grow by 848-863 bytes. If
an infected file is run on December 24th it will stop any other
program run later, displaying the message "Gledileg jol" ("Merry
Christmas") instead. The virus also contains a number of minor changes
and extra NOP instructions.

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Thursday,  4 Jan 1990    Volume 3 : Issue 4

Today's Topics:

Virus biological analogy.
Where to Get Mac Anti-Virals
WHM on Spaffords Theorems
re: Virus Trends
Re: Shrink-wrap Licenses
Re: Anti-virus programs (Mac)
Re: Gatekeeper problems (Mac)
Disk Killer/ Ogre virus
re: The missing viruses (PC)
Spafford's and WHMurray's "Theorems"
8290 & Happy Birthday Jossie VIRUS
DES program (PC)
AIDS note (PC)
Re: Authentication/Signature/Checksum Algorithms

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

---------------------------------------------------------------------------

Date:    Wed, 03 Jan 90 14:28:55 +0000
From:    "Pete Lucas" <[e-mail]>
Subject: Virus biological analogy.

The 'biological' analogy of a computer virus provides a useful model for
computer viruses: As a biologist who computes (rather than a computer
person) there are various things to consider::

1) Disease vector - diskettes, networks, cartridges, WORM disks etc.
2) Incubation period - how long between initial 'infection' and the symptoms
   becoming noticeable.
3) Latency period - how long between infection and the infected machine becomin
g
   able to pass on the infection to another machine.
4) Contagion - how rapidly does the virus spread once it has become activated
5) Damage - what is the severity of infection once it has been activated.
6) Reservoir of infection - the diskettes locked away in your drawer
   for six months, that you 'thought' were clean!!

In biological terms, a 'successful' parasite (since that is what a
virus is) can adopt several strategies. It can be highly infective (so
it gets spread to many new hosts) but have a long latency period (so
the host shows no symptoms until it has been infected for a long
time), or it can be of low infectiveness with a short latency (so if
you catch it, you suffer immediately, but the chance of you catching
it in the first place is low anyway).  Similarly, the harmfulness can
vary. Any parasite that is immediately fatal to its host is going to
get noticed, but if it has been able to pass on the infection before
it 'kills' the host, it will survive - similarly if the virus remains
infective after the host has died, it may still spread.

Computer-viruses we have seen so far tend either to be massively
infective, or have long latencies, or both. This leads them to be
noticed, and people write anti-virus software to combat them.  A virus
that has a very long latency and low infectivity (so it spreads
slowly, unnoticed and unexpected because nothing untoward is
happening) but has a high damage-causing ability when triggered, is
probably the worst thing to contemplate, since it could become
established in a large population of machines unnoticed, then trash
the lot.  I am thinking here of something with a latency of years -
what about a virus that triggers only on February 29th?  The virus
that remains infective even after the 'death' of the host is with us -
your PC may have been crashed, but your diskettes may also be infected
and spread the infection to other machines even though you have
'disinfected' the originally infected machine.  Diskettes will always
act as a reservoir to re-infect otherwise 'clean' machines.

Pete Lucas              [e-mail]

------------------------------

Date:    Wed, 03 Jan 90 09:35:09 -0500
From:    Joe McMahon <[e-mail]>
Subject: Where to Get Mac Anti-Virals

Hi, Mike.

We've set up an automatic distribution service here at Goddard. You
can sign up by sending mail containing the following text to
[e-mail]:

PW ADD yourpassword
AFD ADD VIRUSREM PACKAGE PW=yourpassword
GET VIRUSREM PACKAGE


This will sign you up for updates and will send you the current
version of the package.

 --- Joe M.

P.S. "yourpassword" should be 4 to 8 characters.

------------------------------

Date:    Wed, 03 Jan 90 09:46:00 -0500
From:    [e-mail]
Subject: WHM on Spaffords Theorems

In referring to my comments on Gene's theorems, Brian Piersel asks:

>What about infected programs uploaded to a BBS? If someone else downloads
>that program and uses it, their system will be infected with the same
>virus.  In this case, the media has _not_ moved, which would indicate
>that programs are also a vector for viruses.

The operative words in my comment were "current vector."  While there
always has been a potential for viruses to spread via BBSs, and while
one should be careful when using programs from such sources, that is not
what is happening NOW (examples to the contrary notwithstanding).

In one sense programs are always the vector.  However, it is the sharing
behavior that creates the exposure.  From a behavioral point of view, it
is the media that is being moved around.  While the motive is to move
data, often but not always programs, the particular data to be shared is
incidental to the process of contamination.  If the only spread that we
had to be concerned about was that which resulted from the deliberate
intent to share a particular infected program, we would be in good shape.

While all of the media hype refers to BBSs, they have not been a
significant vector.  Much of the hype also talks about contamination of
vendor shipments.  While there have been a few notable cases, this has
not been the major source of spread.  Even where shrink-wrapped media
has been infected, it was usually after shipment and involved
distributors re-wrapping media that had been returned after use in an
infected machine.

It is important that we know what is really happening, as opposed to
hype, speculation, and potential.

William Hugh Murray, Fellow, Information System Security, Ernst & Young
2000 National City Center Cleveland, Ohio 44114
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840

------------------------------

Date:    Wed, 03 Jan 90 09:05:51 -0500
From:    "W. K. (Bill) Gorman" <[e-mail]>
Subject: re: Virus Trends

>> 2. The press speculation about the DATACRIME virus was much more
>> damaging than the virus.
>
>I don't think so.

I wonder how much such media slobbering tended to encourage subsequent
atrocities, such as the AIDS diskette? Quite a bit, I suspect.

------------------------------

Date:    Wed, 03 Jan 90 12:59:56 -0500
From:    [e-mail]
Subject: Re: Shrink-wrap Licenses

     Recent discussion of the AIDS disk trojan has mentioned licenses that
come with software.  I thought it relevant to post an excerpt (without
permission) of _How to Copyright Software_ by attorney M.J. Salone (3rd ed.
1989 Nolo Press, pages 12/2 - 12/3):

- ---------------------------------------------------------------------------

     Software publishers often attempt to use a so-called "shrink-wrap
license" for the purpose of restricting rights of the purchaser.  If you've
bought software over the counter, you'll be familiar with the sort of license
agreement that's printed on, or enclosed in, the packaging that says something
to the effect that if you break the package seal, you've agreed to the terms of
the license, which limits your rights to use the software.  One common
restriction prohibits modifying the software in any way, even for your own use.
A federal court of appeals struck down a Louisiana statute that authorized this
type of provision on the ground the statute impermissibly conflicted with the
U.S. Copyright Act.*
     Another way software publishers try to restrict the use of over-the-
counter software is to provide an "up-date" or "warranty" card with the
software.  If you sign it, you not only qualify for the warranty
protection or update service offered, but simultaneously agree to the
terms of the "Software Licensing Agreement" included with the package.
This sort of agreement is not likely to be binding in a court of law.
     The warranty offered is often required by law anyway, and the
"updates" are commonly not really updates, but error corrections which,
if uncorrected, would justify your requesting a full refund, or perhaps
even suing the publisher for negligence.

* Vault Corp. v. Quaid Software, 847 F.2d 255 (5th Cir. 1988).
- -------------------------------------------------------------------------

     I wonder how many people know that they may be entitled to FREE
bug fixes or a refund when the software they buy is defective (i.e.
when the product does not perform as advertised).

     In addition to the fact that the licenses may conflict with other
legislation I'd like to point out that many of those "agreements" are
probably not enforceable anyway, since the agreement is inside the box -
prohibiting you from reading it before allegedly agreeing to it.

                                      David R. Brierley
                                      [e-mail]

------------------------------

Date:    Wed, 03 Jan 90 15:09:59 -0500
From:    "Chris Khoury (Sari's Son)" <[e-mail]>
Subject: Re: Anti-virus programs (Mac)

     Reply to Mike on obtaining Gatekeeper, etc.  You can get
Gatekeeper and a lot of other virus programs from
sumex-aim.stanford.edu if you have FTP access. Or thru the listserv on
bitnet, MACSERVE@PUCC, just type: TELL MACSERVE AT PUCC DIR ALL for
the whole directory if files. If you have any other questions feel
free to ask.

Chris Khoury
Acknowledge-To: <3XMQGAA@CMUVM>

[Ed. Also, the monthly information on how to access the comp.virus
archive sites will be sent out shortly.]

------------------------------

Date:    Wed, 03 Jan 90 15:14:52 -0500
From:    "Chris Khoury (Sari's Son)" <[e-mail]>
Subject: Re: Gatekeeper problems (Mac)

Reply to Sean Nolan on Gate Keeper Aid problems:

I had this problem recently too. The problem is in GateKeeper aid, it
locks up the finders resource so the finder can't access it (i think).
Anyways, there are to choices. You can try Eradicate'em, which does
the same thing, or GateKeeper Aid 1.0.1. This fixes that bug. Hope
this helps.

Chris Khoury
Acknowledge-To: <3XMQGAA@CMUVM>

------------------------------

Date:    03 Jan 90 22:12:47 +0000
From:    plains![e-mail] (Brett G. Person)
Subject: Disk Killer/ Ogre virus

Had this little sucker hit my boss' computer yesterday and we don't
know how it got there.  I got a report today from the local technician
who was trying to trace it down that it was even on the masters for
some of the software that was installed.. Neither one of us knows
anything about this thing.  Could someone send me a tech doc on it?
Thanks

Brett G. Person North Dakota State University
uunet!ndsuvax!ncperson | [e-mail] |
[e-mail]

------------------------------

Date:    03 Jan 90 00:00:00 +0000
From:    "David.M..Chess" <[e-mail]>
Subject: re: The missing viruses (PC)

The "Falling Letters Boot Virus" is the name that we use around here
for the boot-sector virus that's also known as "the Israeli Boot Virus"
and "the Swapping Virus".  Hope that clears that one up!

I've heard the name "Palette" used to refer to the 1536 or "Zero Bug"
virus.   I've never been sure where that name came from; I think the
first infected file found was a palette utility, or something like
that?

Vaguely, DC

------------------------------

Date:    03 Jan 90 00:00:00 +0000
From:    "David.M..Chess" <[e-mail]>
Subject: Spafford's and WHMurray's "Theorems"

Shouldn't these really be called "Hypotheses", or something along that
line?  They've certainly not been proven!   *8)

William Murray suggests some more, including:

> 6. The current vector for viruses is floppy disks and diskettes, not
> programs.  That is to say, it is the media, rather than the programs,
> that are moving and being shared.

That's not particularly true, I don't think.   Both disk/ette based
and program based viruses are spreading at the moment.   The most
widespread virus in the PC area is the 1813 ("Jerusalem"), which is
program-based; its vector is program files (generally .EXE or .COM),
not media.

DC

------------------------------

Date:    04 Jan 90 02:39:48 +0000
From:    nsc![e-mail] (Balaji Pitchaikani)
Subject: 8290 & Happy Birthday Jossie VIRUS

Hi,
     Has anyone heard about "8290" and "Happy Birthday Jossie" virues.
These virus are very popular in India. If you have any info on them
please post me details. I will summarize to the net, if there is
enough interest.

Thanks in advance,

Balaji
([e-mail])

------------------------------

Date:    Thu, 04 Jan 90 10:36:18 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: DES program (PC)

[e-mail] (Timo Kiravuo) writes

> As to what this has to do with viruses, I don't know, but I think
> that a public DES implementation might be interesting enough to
> many people in the virus field, so maybe the moderator will be
> nice and let this pass.

There is a W-German DES program available for PC compatible computers.
It is called PC-DES, and is distributed as "charityware".  It is
currently used by a number of people, including myself, when we have
to send "live" viruses in E-mail.

If anybody is interested, I can E-mail copies of it (xxencoded PKARC
file).  Since I am located in Iceland, I am of course not restricted
by US regulations.  Just be careful - if somebody in the USA receives
a copy, it is probably illegal so send a copy back out of country.

- -frisk

------------------------------

Date:    Thu, 04 Jan 90 10:57:12 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: AIDS note (PC)

As far as I know, only one company has received the AIDS diskette here
in Iceland. The name of that company was not obtained from any of the
mailing lists already mentioned.

This company is the Toshiba computer distributor here in Iceland. The
name of this company appears in various ads from Toshiba, where it
contains one (minor) error. The label contained the same error, so it
is safe to assume that those ads were the source used. I assume that
other companies mentioned in the Toshiba ads also received the trojan.

And yes - They had thrown the envelope away, but said it had been
posted in Panama.

- -frisk

------------------------------

Date:    Thu, 04 Jan 90 13:01:04 +0200
From:    Y. Radai <[e-mail]>
Subject: Re: Authentication/Signature/Checksum Algorithms

  In V2 #258 Ralph Merkle referred to previous discussions in this
group on authentication algorithms, and suggested his own one-way
hash function Snefru which has the advantage of not requiring secret
information and which has better performance than a DES-based system.
It's my understanding that the advantages of Snefru are its much
faster software implementation and possibility of larger key size than
DES, and several ways of choosing between greater security and greater
speed.
  So Ralph Merkle recommends Snefru and Bob Bosen recommends the DES-
based X9.9 (he also mentions ISO 8731-2).  And going outside of this
forum we find that Fred Cohen recommends an RSA-based algorithm, Ro-
bert Jueneman recommends his Quadratic Congruential MDC, Prof. Rabin
recommends the CRC algorithm using a randomly selected irreducible
polynomial, and so forth.  Interestingly, none of these authors seems
to give any argumentation why his algorithm is any better than the
others (except for Merkle's comparison of Snefru with DES).

  Bob Bosen says in Issue 265 that a sophisticated authentication al-
gorithm is clearly better than some programmer's guess at an authenti-
cation algorithm (he now adds the condition that both implementing
programs are well-written and convenient and "apply the algorithm
across all program code without exception").
  I can't say that this is incorrect, but even with this addition, I
still don't share his emphasis on sophistication of the algorithm.
The added sophistication of (say) X9.9, compared to CRC with a person-
ally chosen generator, may be well worth the added time in the case of
authentication of bank transfers and other conventional applications.
But have you considered the possibility, Bob, that this sophistication
may be wasted when dealing with viruses?
  If we were to try to draw a graph showing sophistication on the X-
axis and security on the Y-axis, I think everyone would agree that the
curve "levels off", i.e. there is a certain point, beyond which making
the algorithm more sophisticated has negligible value in increasing
security.  The difference between the positions of Bob, Ross Green-
berg, and myself is partly where we think the curve levels off.  Bob's
position is that this happens only at a late stage of sophistication,
while Ross seems to think it happens at a very early stage.  My opin-
ion is that for *anti-viral purposes* this point is reached much ear-
lier than for more ordinary uses of authentication algorithms, though
not quite as early as Ross believes.
  The reason I think the anti-viral situation is special is that in
this environment there are considerations which probably have no coun-
terpart in ordinary message authentication.  For example:
  (1) A virus must perform all its work, including circumvention of
anti-viral protection (e.g. forging of checksums) if that's what its
author desires, on the computer which it's attacking and in a very
short time (short enough so that it will not be noticed by the user).
  (2) By its very nature, a virus is designed to attack a large per-
centage of the users of a particular system.  From the point of view
of the virus writer, any technique which results in circumventing the
anti-viral protection of only a single user (or a very few users) is
not worthwhile, since if that were what he desired, he could achieve
the same thing much more easily by means of an immediate-acting Tro-
jan, and against that *no* alteration-detecting program, no matter how
sophisticated, can warn us in time.
  (3) Ordinarily, a virus writer is not in a position to know what
checksum algorithms may be in use on the computers on which his virus
is unleashed.  And any technique for forging the checksums of one al-
gorithm will probably not work against any other checksum algorithm.
Therefore a checksum-forging technique would increase the percentage
of disks infected by only a very small amount, making it a waste of
time and effort from his point of view.  (An exception would occur if
the virus author is satisfied with attacking an environment which is
sufficiently limited so that most computers in it use the same check-
sum program.)

  Taking these conditions, mainly (1), into account, it seems to me
that a checksum algorithm, expressed as a function F on files, will
provide sufficient security for anti-viral purposes if the following
two conditions are satisfied:
  (A) For any given file f, F(f) is (in general) different for each
computer.  (This condition amounts essentially to requiring a key
unique to each computer.)
  (B) Given a file f, it is computationally infeasible (without know-
ledge of the key) to construct a file f' from it containing the de-
sired addition of (or replacement of ordinary code by) viral code such
that F(f') = F(f).
  In making this claim, it is assumed that the checksum base, key and
program are kept offline (i.e. not located on an accessible disk or in
memory while a virus may be active), thus preventing discovery or com-
putation of the user's key or circumvention of the checksum program.

  If the above opinion is correct, then I think that all the algori-
thms mentioned in the second paragraph of this posting are adequate
for anti-viral purposes, including the relatively unsophisticated CRC
algorithm if the generator is selected randomly or personally, and
hence the added sophistication of algorithms such as X9.9 is wasted in
view of the extra run time which they require.
  Concerning speed, it can be argued that we shouldn't exclude slower
algorithms, since the more algorithms which are in use, the less
worthwhile it will be for anyone to try checksum-forging techniques.
On the other hand, if one algorithm has a clear superiority over the
others in speed, users are hardly likely to choose a slower algorithm
because of such an argument.  And when speed is the issue it seems to
me that CRC, because of its greater simplicity, is better than any of
the more sophisticated algorithms satisfying conditions (A) and (B).

  It's possible, of course, that I'm wrong on one or more opinions ex-
pressed above:  Perhaps Dr. Merkle or some other crypto-expert can
show that conditions (A) and (B) are not sufficient even in the viral
environment expressed by (1)-(3) above, so that CRC, even with a ran-
dom generator, is insecure.  Or that I'm wrong in assuming that such
a CRC satisfies these conditions.  Or perhaps some other algorithm is
faster than CRC and no less secure.  But what is needed is evidence
and argumentation relative to the *viral environment*, and this I
have not yet seen in Bob's writings.

  I now come to Ross Greenberg's posting in Issue 266.  Now I fully
agree with him that sophisticated checkers may go unused because of
the time required.  But Ross implies that users will always prefer a
"good enough" fast checker like that of FluShot+ over a slow sophisti-
cated one.  But can we be so sure that FluShot+ is really good enough?
How many of its users have the slightest idea how its security com-
pares with that of other programs?  I don't know whether his algorithm
satisfies condition (B) above, but it certainly does not satisfy (A),
i.e. for any given file all users will get the same checksum, and
that's a potential security hole, at least in the "limited environment"
situation mentioned at the end of (3) above.  But since this hole can
be plugged very simply and at no cost in speed, why not do so, Ross?

  One final remark.  Bob Bosen writes:
>In his mailing of Dec 07 '89, Y. Radai seems to be taking the position
>that since I am in favor of sophisticated authentication algorithms, I
>must be against sophisticated program implementations. Nothing could
>be further from the truth.

  Such a position may indeed be far from the truth.  But so is the no-
tion that I was taking such a position!  I was not assuming that you
were *against* sophisticated program implementations; I was merely
concerned by your not having *mentioned* the need for very careful im-
plementation in a given system.  That's a big difference.

                                     Y. Radai
                                     Hebrew Univ. of Jerusalem, Israel
                                     [e-mail]

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Friday,  5 Jan 1990    Volume 3 : Issue 5

Today's Topics:

Gatekeeper/Disinfectant Problem! (Mac)
Re: Virus Trends (and FAXes on PCs)
SCANV53 (PC)
Introduction to the anti-viral archives
UNIX anti-viral archive sites
Apple II anti-viral archive sites
Atari ST anti-viral archive sites
Amiga anti-viral archive sites
Macintosh anti-viral archive sites
IBMPC anti-viral archive sites
Documentation anti-viral archive sites
Uses of MACs Against Viruses
VIRUS-L Digest V3 #4

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

---------------------------------------------------------------------------

Date:    Thu, 04 Jan 90 12:04:00 -0400
From:    Michael Greve <[e-mail]>
Subject: Gatekeeper/Disinfectant Problem! (Mac)

     I originally sent out this message on MACNET but nobody could help.
    We have a networked lab with 16 machines.  We have both Gatekeeper and
    Gatekeeper Aid.  We are currently using Disinfectant 1.5.  We can use
    Disinfectant to check each machine for viruses but when we actually
    try and disinfect a machine we get a Gatekeeper violation message.  I've
    set Gatekeeper correctly but still it won't let me disinfect.  I used
    the Gatekeeper settings that are mentioned in the about section of
    Disinfectant.  Still it will not work.  The only way I can disinfect the
    lab machines is to boot up off a floppy (that doesn't have Gatekeeper on
    it) and then run disinfectant.  This can be a hassle on the consultants
    machine when students come in and have various viruses on their disks.

      We also have SAM and have set that in Gatekeeper but still get the
    same message when trying to disinfect.  Any ideas, help or assistance
    would be greatly appreciated.

                                                Michael Greve
                                                U. of Pa.
                                                Wharton Computing
                                                [e-mail]

------------------------------

Date:    04 Jan 90 17:40:26 +0000
From:    [e-mail] (Ralph A. Shaw)
Subject: Re: Virus Trends (and FAXes on PCs)

[e-mail] says:

>     - A FAX message is a bitstream interpreted by an interpreter at
>       the receving end.  Could it be induced to do something interesting
>       through the use of illegal bit patterns?  Group III is probably too
>       simple to be attacked, but group IV?  Imagine a message which
>       causes a FAX machine to send an extra copy of transmitted documents
>       to another location.

Something that has come to the attention of security paranoids here
lately is that some manufacturers of PC FAX boards have added a
feature that allows the FAX modem to be used as a bisync modem to
communicate with the PC directly, rather than transmitting just FAXes.

I assume the PC would have to be running some software to enable it
and reassign the console (requiring local intervention), but a
networked PC could then prove to be a leak onto the corporate network,
(or at least, for handy distribution of the Trojan-of-the-month program).
Added to this is the promise that at least one FAXboard vendor
promises that both async and bisync modem capability will be available
in the future.

I don't have the details of which boards provide this "feature",
or of what functionality is really there via this inboard modem
and accompanying software, but will pass on any other details I can
ferret out.
- --
Ralph Shaw                      [e-mail]

------------------------------

Date:    Thu, 04 Jan 90 10:24:40 -0800
From:    [e-mail]
Subject: SCANV53 (PC)

The following is forwarded from John McAfee:

        SCAN Version 53 has a serious problem with false alarms on the 4096
virus.  The version was unfortunately included in the last-minute monthly
FidoNet distribution and is therefore in the hands of a lot of people.  If
you have version 53 of SCAN please do not use it.  Version 54 is available
on CompuServe, Homebase and most of the Fidonet hubs.  My apologies to
anyone inconvenienced by my error.
John McAfee

------------------------------

Date:    04 Jan 90 03:26:11 +0000
From:    [e-mail] (Jim Wright)
Subject: Introduction to the anti-viral archives


# Introduction to the Anti-viral archives...
# Listing of 03 January 1990

This posting is the introduction to the "official" anti-viral archives
of VIRUS-L/comp.virus.  With the generous cooperation of many sites
throughout the world, we are attempting to make available to all
the most recent news and programs for dealing with the virus problem.
Currently we have sites for Amiga, Apple II, Atari ST, IBMPC, Macintosh
and Unix computers, as well as sites carrying research papers and
reports of general interest.

If you have general questions regarding the archives, you can send
them to this list or to me.  I'll do my best to help.  If you have a
submission for the archives, you can send it to me or to one of the
persons in charge of the relevant sites.

If you have any corrections to the lists, please let me know.

The files contained on the participating archive sites are provided freely
on an as-is basis.

To the best of our knowledge, all files contained in the archives are either
Public Domain, Freely Redistributable, or Shareware.  If you know of one
that is not, please drop us a line and let us know.  Reports of corrupt
files are also welcome.

PLEASE NOTE
The Managers of these systems, and the Maintainers of the archives, CAN NOT
and DO NOT guarantee any of these applications for any purpose.  All possible
precautions have been taken to assure you of a safe repository of useful
tools.

- --
Jim Wright
[e-mail]


------------------------------

Date:    04 Jan 90 03:31:23 +0000
From:    [e-mail] (Jim Wright)
Subject: UNIX anti-viral archive sites


# Anti-viral and security archive sites for Unix
# Listing last changed 30 September 1989

attctc
        Charles Boykin <[e-mail]>
        Accessible through UUCP.

cs.hw.ac.uk
        Dave Ferbrache <[e-mail]>
        NIFTP from JANET sites, login as "guest".
        Electronic mail to <[e-mail]>.
        Main access is through mail server.
        The master index for the virus archives can be retrieved as
                request: virus
                topic: index
        For further details send a message with the text
                help
        The administrative address is <[e-mail]>

sauna.hut.fi
        Jyrki Kuoppala <[e-mail]>
        Accessible through anonymous ftp, IP number 128.214.3.119.
        (Note that this IP number is likely to change.)

ucf1vm
        Lois Buwalda <[e-mail]>
        Accessible through...

wuarchive.wustl.edu
        Chris Myers <[e-mail]>
        Accessible through anonymous ftp, IP number 128.252.135.4.
        A number of directories can be found in ~ftp/usenet/comp.virus/*.

- --
Jim Wright
[e-mail]


------------------------------

Date:    04 Jan 90 03:29:54 +0000
From:    [e-mail] (Jim Wright)
Subject: Apple II anti-viral archive sites


# Anti-viral archive sites for the Apple II
# Listing last changed 30 September 1989

brownvm.bitnet
        Chris Chung <[e-mail]>
        Access is through LISTSERV, using SEND, TELL and MAIL commands.
        Files are stored as
                apple2-l xx-xxxxx
        where the x's are the file number.

cs.hw.ac.uk
        Dave Ferbrache <[e-mail]>
        NIFTP from JANET sites, login as "guest".
        Electronic mail to <[e-mail]>.
        Main access is through mail server.
        The master index for the virus archives can be retrieved as
                request: virus
                topic: index
        The Apple II index for the virus archives can be retrieved as
                request: apple
                topic: index
        For further details send a message with the text
                help
        The administrative address is <[e-mail]>

uk.ac.lancs.pdsoft
        Steve Jenkins <[e-mail]>
        Service for UK only; no access from BITNET/Internet/UUCP
        Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft"
        FTP       : call lancs.pdsoft, user "pdsoft", pwd "pdsoft".
        Pull the file "help/basics" for starter info, "micros/index" for index.
        Anti-Viral stuff is held as part of larger micro software collection
        and is not collected into a distinct area.

- --
Jim Wright
[e-mail]


------------------------------

Date:    04 Jan 90 03:30:11 +0000
From:    [e-mail] (Jim Wright)
Subject: Atari ST anti-viral archive sites


# Anti-viral archive sites for the Atari ST
# Listing last changed 30 September 1989

cs.hw.ac.uk
        Dave Ferbrache <[e-mail]>
        NIFTP from JANET sites, login as "guest".
        Electronic mail to <[e-mail]>.
        Main access is through mail server.
        The master index for the virus archives can be retrieved as
                request: virus
                topic: index
        The Atari ST index for the virus archives can be retrieved as
                request: atari
                topic: index
        For further details send a message with the text
                help
        The administrative address is <[e-mail]>.

panarthea.ebay
        Steve Grimm <[e-mail]>
        Access to the archives is through mail server.
        For instructions on the archiver server, send
                help
        to <[e-mail]>.

uk.ac.lancs.pdsoft
        Steve Jenkins <[e-mail]>
        Service for UK only; no access from BITNET/Internet/UUCP
        Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft"
        FTP       : call lancs.pdsoft, user "pdsoft", pwd "pdsoft".
        Pull the file "help/basics" for starter info, "micros/index" for index.
        Anti-Viral stuff is held as part of larger micro software collection
        and is not collected into a distinct area.

- --
Jim Wright
[e-mail]


------------------------------

Date:    04 Jan 90 03:29:34 +0000
From:    [e-mail] (Jim Wright)
Subject: Amiga anti-viral archive sites


# Anti-viral archive sites for the Amiga
# Listing last changed 30 September 1989

cs.hw.ac.uk
        Dave Ferbrache <[e-mail]>
        NIFTP from JANET sites, login as "guest".
        Electronic mail to <[e-mail]>.
        Main access is through mail server.
        The master index for the virus archives can be retrieved as
                request: virus
                topic: index
        The Amiga index for the virus archives can be retrieved as
                request: amiga
                topic: index
        For further details send a message with the text
                help
        The administrative address is <[e-mail]>

ms.uky.edu
        Sean Casey <[e-mail]>
        Access is through anonymous ftp.
        The Amiga anti-viral archives can be found in /pub/amiga/Antivirus.
        The IP address is 128.163.128.6.

uk.ac.lancs.pdsoft
        Steve Jenkins <[e-mail]>
        Service for UK only; no access from BITNET/Internet/UUCP
        Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft"
        FTP       : call lancs.pdsoft, user "pdsoft", pwd "pdsoft".
        Pull the file "help/basics" for starter info, "micros/index" for index.
        Anti-Viral stuff is held as part of larger micro software collection
        and is not collected into a distinct area.

uxe.cso.uiuc.edu
        Mark Zinzow <[e-mail]>
        Lionel Hummel <[e-mail]>
        The archives are in /amiga/virus.
        There is also a lot of stuff to be found in the Fish collection.
        The IP address is 128.174.5.54.
        Another possible source is uihub.cs.uiuc.edu at 128.174.252.27.
        Check there in /pub/amiga/virus.

- --
Jim Wright
[e-mail]


------------------------------

Date:    04 Jan 90 03:31:05 +0000
From:    [e-mail] (Jim Wright)
Subject: Macintosh anti-viral archive sites


# Anti-viral archive sites for the Macintosh
# Listing last changed 07 November 1989

cs.hw.ac.uk
        Dave Ferbrache <[e-mail]>
        NIFTP from JANET sites, login as "guest".
        Electronic mail to <[e-mail]>.
        Main access is through mail server.
        The master index for the virus archives can be retrieved as
                request: virus
                topic: index
        The Mac index for the virus archives can be retrieved as
                request: mac
                topic: index
        For further details send a message with the text
                help
        The administrative address is <[e-mail]>

ifi.ethz.ch
        Danny Schwendener <[e-mail]>
        Interactive access through DECnet (SPAN/HEPnet):
                $SET HOST 57434  or $SET HOST AEOLUS
                Username: MAC
        Interactive access through X.25 (022847911065) or Modem 2400 bps
        ([phone]):
                # CALL B050 <cr><cr>
                Username: MAC
        Files may also be copied via DECnet (SPAN/HEPnet) from
                57434::DISK8:[MAC.TOP.LIBRARY.VIRUS]

rascal.ics.utexas.edu
        Werner Uhrig <[e-mail]>
        Access is through anonymous ftp, IP number is 128.83.144.1.
        Archives can be found in the directory mac/virus-tools.
        Please retrieve the file 00.INDEX and review it offline.
        Due to the size of the archive, online browsing is discouraged.

scfvm.bitnet
        Joe McMahon <[e-mail]>
        Access is via LISTSERV.
        SCFVM offers an "automatic update" service.  Send the message
                AFD ADD VIRUSREM PACKAGE
        and you will receive updates as the archive is updated.
        You can also subscribe to automatic file update information with
                FUI ADD VIRUSREM PACKAGE

sumex-aim.stanford.edu
        Bill Lipa <[e-mail]>
        Access is through anonymous ftp, IP number is 36.44.0.6.
        Archives can be found in /info-mac/virus.
        Administrative queries to <[e-mail]>.
        Submissions to <[e-mail]>.
        There are a number of sites which maintain shadow archives of
        the info-mac archives at sumex:
        * MACSERV@PUCC          services the Bitnet community
        * LISTSERV@RICE         for e-mail users
        * FILESERV@IRLEARN      for folks in Europe

uk.ac.lancs.pdsoft
        Steve Jenkins <[e-mail]>
        Service for UK only; no access from BITNET/Internet/UUCP
        Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft"
        FTP       : call lancs.pdsoft, user "pdsoft", pwd "pdsoft".
        Pull the file "help/basics" for starter info, "micros/index" for index.
        Anti-Viral stuff is held as part of larger micro software collection
        and is not collected into a distinct area.

wsmr-simtel20.army.mil
        Robert Thum <[e-mail]>
        Access is through anonymous ftp, IP number 26.2.0.74.
        Archives can be found in PD3:<MACINTOSH.VIRUS>.
        Please get the file 00README.TXT and review it offline.

- --
Jim Wright
[e-mail]


------------------------------

Date:    04 Jan 90 03:30:47 +0000
From:    [e-mail] (Jim Wright)
Subject: IBMPC anti-viral archive sites


# Anti-viral archive for the IBMPC
# Listing last changed 16 December 1989

cs.hw.ac.uk
        Dave Ferbrache <[e-mail]>
        NIFTP from JANET sites, login as "guest".
        Electronic mail to <[e-mail]>.
        Main access is through mail server.
        The master index for the virus archives can be retrieved as
                request: virus
                topic: index
        The IBMPC index for the virus archives can be retrieved as
                request: ibmpc
                topic: index
        For further details send a message with the text
                help
        The administrative address is <[e-mail]>

f.ms.uky.edu
        Daniel Chaney <[e-mail]>
        This site can be reached through anonymous ftp.
        The IBMPC anti-viral archives can be found in /pub/msdos/AntiVirus.
        The IP address is 128.163.128.6.

mibsrv.mib.eng.ua.edu
        James Ford <[e-mail]> <[e-mail]>
        This site can be reached through anonymous ftp.
        The IBM-PC anti-virals can be found in PUB/IBM-ANTIVIRUS
        Uploads to PUB/IBM-ANTIVIRUS/00UPLOADS.  Uploads are screened.
        Requests to [e-mail] for UUENCODED files will be filled
        on a limited bases as time permits.
        The IP address is 130.160.20.80.

uk.ac.lancs.pdsoft
        Steve Jenkins <[e-mail]>
        Service for UK only; no access from BITNET/Internet/UUCP
        Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft"
        FTP       : call lancs.pdsoft, user "pdsoft", pwd "pdsoft".
        Pull the file "help/basics" for starter info, "micros/index" for index.
        Anti-Viral stuff is held as part of larger micro software collection
        and is not collected into a distinct area.

uxe.cso.uiuc.edu
        Mark Zinzow <[e-mail]>
        This site can be reached through anonymous ftp.
        The IBMPC anti-viral archives are in /pc/virus.
        The IP address is 128.174.5.54.

vega.hut.fi
        Timo Kiravuo <[e-mail]>
        This site (in Finland) can be reached through anonymous ftp.
        The IBMPC anti-viral archives are in /pub/pc/virus.
        The IP address is 130.233.200.42.

wsmr-simtel20.army.mil
        Keith Peterson <[e-mail]>
        Direct access is through anonymous ftp, IP 26.2.0.74.
        The anti-viral archives are in PD1:<MSDOS.TROJAN-PRO>.
        Simtel is a TOPS-20 machine, and as such you should use
        "tenex" mode and not "binary" mode to retreive archives.
        Please get the file 00-INDEX.TXT using "ascii" mode and
        review it offline.
        NOTE:
        There are also a number of servers which provide access
        to the archives at simtel.
        WSMR-SIMTEL20.Army.Mil can be accessed using LISTSERV commands
        from BITNET via LISTSERV@NDSUVM1, LISTSERV@RPIECS and in Europe
        from EARN TRICKLE servers.  Send commands to TRICKLE@<host-name>
        (for example: TRICKLE@AWIWUW11).  The following TRICKLE servers
        are presently available: AWIWUW11 (Austria), BANUFS11 (Belgium),
        DKTC11 (Denmark), DB0FUB11 (Germany), IMIPOLI (Italy),
        EB0UB011 (Spain) and TREARN (Turkey).

- --
Jim Wright
[e-mail]


------------------------------

Date:    04 Jan 90 03:30:29 +0000
From:    [e-mail] (Jim Wright)
Subject: Documentation anti-viral archive sites


# Anti-viral archive sites for documentation
# Listing last changed 03 January 1990

cert.sei.cmu.edu
        Kenneth R. van Wyk <[e-mail]>
        Access is available via anonymous ftp, IP number 128.237.253.5.
        This site maintains archives of all VIRUS-L digests, all
        CERT advisories, as well as a number of informational documents.
        VIRUS-L/comp.virus information is in:
                ~ftp/pub/virus-l/archives
                ~ftp/pub/virus-l/archives/predigest
                ~ftp/pub/virus-l/archives/1988
                ~ftp/pub/virus-l/archives/1989
                ~ftp/pub/virus-l/docs
        CERT advisories are in:
                ~ftp/pub/cert_advisories


cs.hw.ac.uk
        Dave Ferbrache <[e-mail]>
        NIFTP from JANET sites, login as "guest".
        Electronic mail to <[e-mail]>.
        Main access is through mail server.
        The master index for the virus archives can be retrieved as
                request: virus
                topic: index
        The index for the **GENERAL** virus archives can be retrieved as
                request: general
                topic: index
        The index for the **MISC.** virus archives can be retrieved as
                request: misc
                topic: index
        **VIRUS-L** entries are stored in monthly and weekly digest form from
        May 1988 to December 1988.  These are accessed as log.8804 where
        the topic substring is comprised of the year, month and a week
        letter.  The topics are:
                8804, 8805, 8806 - monthly digests up to June 1988
                8806a, 8806b, 8806c, 8806d, 8807a .. 8812d - weekly digests
        The following daily digest format started on Wed 9 Nov 1988.  Digests
        are stored by volume number, e.g.
                request: virus
                topic: v1.2
        would retrieve issue 2 of volume 1, in addition v1.index, v2.index and
        v1.contents, v2.contents will retrieve an index of available digests
        and a extracted list of the the contents of each volume respectively.
        **COMP.RISKS** archives from v7.96 are available on line as:
                request: comp.risks
                topic: v7.96
        where topic is the issue number, as above v7.index, v8.index and
        v7.contents and v8.contents will retrieve indexes and contents lists.
        For further details send a message with the text
                help
        The administrative address is <[e-mail]>

lehiibm1.bitnet
        Ken van Wyk <[e-mail]> new: <[e-mail]>
        This site has archives of VIRUS-L, and many papers of
        general interest.
        Access is through ftp, IP address 128.180.2.1.
        The directories of interest are VIRUS-L and VIRUS-P.

uk.ac.lancs.pdsoft
        Steve Jenkins <[e-mail]>
        Service for UK only; no access from BITNET/Internet/UUCP
        Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft"
        FTP       : call lancs.pdsoft, user "pdsoft", pwd "pdsoft".
        Pull the file "help/basics" for starter info, "micros/index" for index.
        Anti-Viral stuff is held as part of larger micro software collection
        and is not collected into a distinct area.

unma.unm.edu
        Dave Grisham <[e-mail]>
        This site has a collection of ethics documents.
        Included are legislation from several states and policies
        from many institutions.
        Access is through ftp, IP address 129.24.8.1.
        Look in the directory /ethics.

- --
Jim Wright
[e-mail]


------------------------------

Date:    Thu, 04 Jan 90 14:33:00 -0500
From:    [e-mail]
Subject: Uses of MACs Against Viruses

First, let me take this occasion to apologize to Y. Radai for my
offenses of style and hyperbole.  Then I would like to comment on his
discussion that appeared in VIRUS-L, Vol. 3, Issue 4 on the indicated
cross-over point for sophistication of the algorithm in generating
authenticators for programs.

I tend to agree with most of his observation as they relate to the use
of the authenticator to recognize the contamination of a program in
the target execution environment.  However, I think that I speak for
Bob Bosen as well as myself when I suggest that we both have in mind
another use.

Bob posits the use of a MAC to ensure that programs are received as they
were shipped.  This use offers some protection against contamination of
a program during transit from its trusted author to the point of use.

I go a little further.  I suggest that programs be digitally signed by
their originators.  (For more reasons than need be listed here, I
currently recommend RSA MailSafe for this application.  This is a
hybrid implementation which uses a block-product cipher for processing
the program and RSA for key-management and distribution.)  This use
not only enables the user to know that the program has not been
changed since original shipment from the author, but also enables the
author to disown any late changes.  If the end-user does not know or
trust the author, but relies upon some inter-mediate authority, such
as the NCSC, or his own management, then the program can be
countersigned by this authority.

Note that for this application more time and resource would be
available for an attack.  In addition multiple people would have to
rely upon the same algorithm or mechanism.  These two requirements
argue for a strong alogrithm of known strength, i.e., a "standard"
one.

We argue that the provenance of a program or other data item is
essential to confidence in it.  Immutability contributes.  While
immutable media, such as CD-ROM, and a record of custody can be made
to work in special cases, digital signatures can be made to work in
most.  They are independent of the media and move with the program.

Thus we argue for an additional use that has different requirements
than those considered by the other discussions.

William Hugh Murray, Fellow, Information System Security, Ernst & Young
2000 National City Center Cleveland, Ohio 44114
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840

------------------------------

Date:    Thu, 04 Jan 00 19:90:52 +0000
From:    [e-mail] (Ross M. Greenberg)
Subject: VIRUS-L Digest V3 #4

>  I now come to Ross Greenberg's posting in Issue 266.
>  ...But Ross implies that users will always prefer a
>"good enough" fast checker like that of FluShot+ over a slow sophisti-
>cated one.  But can we be so sure that FluShot+ is really good enough?

Well, I didn't mean to imply that the method used in my own code was
sophisticated at all.  However, to date, it seems to be good enough:
no virus infection on a checksummed program has gotten through (to my
users knowledge, naturally) without detection. I can only assume that
lack of reporting can be equated to lack of infection -- I know that
such thinking leads to strange numbers coming from strange organizations
and (as such) can just ask you to prefix everything below with an "I
think" or an "I feel".

Anyway, that's what I mean by "good enough".  For those users really
worried over things, two checkers would be a good idea.

>How many of its users have the slightest idea how its security com-
>pares with that of other programs?

The users have to trust the program author of any security product.  As
such, they have to trust that, if a virus were to infect files with a
"zero differential" on the checksumming method I use, that I'd change
the checksuming method.  Yes, there has to be a trust in your vendor.

The real world and the theoretical world do not always agree....

>  I don't know whether his algorithm
>satisfies condition (B) above, but it certainly does not satisfy (A),
>i.e. for any given file all users will get the same checksum, and
>that's a potential security hole, at least in the "limited environment"
>situation mentioned at the end of (3) above.  But since this hole can
>be plugged very simply and at no cost in speed, why not do so, Ross?

Easy to code - murder to support!  I have about 15,000 registered users.
They call me with the slightest problem - as they should, and as they're
entitled to. If they ask me: "Is my COMMAND.COM file infected?", I need
simply ask them what the checksum is.  From that I know the answer.  If
I used some method to generate unique checksums for each user, I'd still
have to have some means to get back to the "real" checksum.  If I could
do that, so could a bad guy, rendering inconvienence only to the bad guy,
and potentially to thousands of users (I average about 50 tech support
calls per day on a $14 product!)

Please understand that I certainly can appreciate the limitations of using
a less sophisticated algorithm within my code as versus something wonderfully
complex.  But, as with any security product, I had to weigh off security
versus convienience considerations.  I like to think I did an ok job of it:
those in doubt need simply use *any* other checksumming type program in
combination with my own to see if I'm right!

Ross M. Greenberg
Author, FLU_SHOT+

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Monday,  8 Jan 1990    Volume 3 : Issue 6

Today's Topics:

re: comment by William Hugh Murray
Re: Spafford's Theorems
Gatekeeper Privileges (MAC)
Questioning ethics at computing sites
The Amstrad virus (PC)
Re: Where to Get Mac Anti-Virals
Jerusalem B problem (PC)
Re: Authentication/Signature/Checksum Algorithms
Re: Virus Trends (and FAXes on PCs)
Alternative Virus Protection (Mac)
Murray's Theorems (Was Re: Spafford's Theorems)
Implied Loader 'Pack' Virus (Mac)
Re: Virus Trends (and FAXes on PCs)
Re: Viruses Rhyme And Reason

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

---------------------------------------------------------------------------

Date:    Thu, 04 Jan 90 23:01:00 -0500
From:    "Gerry Santoro - CAC/PSU 814-863-4356" <[e-mail]>
Subject: re: comment by William Hugh Murray

In V3 N1 of Virus-L Digest, William Hugh Murray wrote:

>2. The press speculation about the DATACRIME virus was much more
>damaging than the virus.

For the sake of academic argument I would dispute this.  I agree that the
actual damage from Datacrime (or Oct 13 or whatever) was minimal, and
virtually nonexistent on our campuses, and I would also agree that there
was mucho media hype.  However, I really think that there was a major
benefit to all of this.

As Mr. Murray correctly pointed out, much more users damage their own
data than are damaged by 'nasty' software.  The Oct 13 scare made our users,
who number in the tens of thousands,  FINALLY listen to our pleadings
to make backup copies of their software and data.

The situation is similar to that with seat belts.  Few of us are actually
in an accident, but if we see one (or the effects) it may cause us to wear
the belts, which *may* save our lives.  In the case of the Oct 12  virus
we had one grand  chance to get people to listen to our message regarding
making backups and preparing for the chance of disaster, whether by
accident, ignorance, hardware failure or 'nasty' software.

-
 -------------------------------------------------------------------------------
|   |        gerry santoro, ph.d.  --  center for academic computing      |   |
| -(*)-  penn state university -- [e-mail] -- [e-mail] -(*)- |
|   |             standard disclaimer -->  "I yam what I yam"             |   |
-
 -------------------------------------------------------------------------------

------------------------------

Date:    Fri, 05 Jan 90 04:46:06 +0000
From:    [e-mail] (John Campbell)
Subject: Re: Spafford's Theorems

[e-mail] writes:
> 1. The amount of damage to data and availability done by viruses to date
> has been less than users do to themselves by error every day.

        OK, OK.  True enough, though we don't often like to be reminded of
        this.

> 4. Viruses and rumors of viruses have the potential to destroy society's
> already fragile trust in our ability to get computers to do that which
> we intend while avoiding unintended adverse consequences.

        This is the most worrying aspect of virus/trojan/worm infections.
        We have a population which has no intrinsic immune system which
        leaves itself open to such attack.  Vectors now consist of
        communications networks (BBS and other means) as well as physical
        media.  Since we are moving towards a networked future we will
        need immune systems in our computers-  society (all of us) are
        currently subject to these terrorist acts (like the tylenol
        scare).  Remember-  any linchpin/choke point in technology, be
        it transportation, food delivery, water supply, communications
        is subject to interruption by killers.  Set some of these loose
        in a Hospital and the virus writer is _at least_ as dangerous
        as the individual who slips cyanide into food and drug products.

> 5. We learn from the biological analogy that viruses are self-limiting.

        We also learn that when the population is large enough for the
        entity to take advantage of, an entity will attempt to take
        hold.  Once we had standard PC's (and Macs, Amigas, etc) we
        then had a "fixed" cellular mechanism to subvert.  S-100 systems
        which lacked such standardization were not subject;  even the
        "standard" S-100 systems did not constitute a large enough
        population to invite attack...

> Clinically, if you catch a cold, you will either get over it, or you
> will die.  Epidemiologically, a virus in a limited population
> will either make its hosts immune, or destroy the population.  Even in
> open population, a virus must have a long incubation period and slow
> replication in order to be successful (that is, replicate and spread).

        Point taken.  A virus, since it _does_ act in the system as
        non-invasively as possible (beyond spreading its "genetic code"
        wherever possible) will be fairly successful.  Subtlety pays
        off.  Of course, these viruses are much like the HIV will eventually
        kill the host...

- --
 John R. Campbell       ...!uunet!lgnp1!penrij!soup       ([e-mail])
                 "In /dev/null no one can hear you scream"

------------------------------

Date:    Fri, 05 Jan 90 07:57:45 -0500
From:    [e-mail]
Subject: Gatekeeper Privileges (MAC)

Hi,

     Before I install Gatekeeper, I was wondering if anyone knows
the set of privileges required by the TextPac and PublishPac software.
We are using a Dest page scanner in our public access lab.  The device
is configured SCSI in order to talk to the MAC II so I think I'm correct
in assuming that in order to scan text and pictures the software will
need to do all sorts of low level stuff.

     Anyone else out there with Gatekeeper and a Dest scanner installed?

                       Andy Wing
                       Senior Analyst
                       Temple University School of Medicine

------------------------------

Date:    Fri, 05 Jan 90 09:28:30 -0500
From:    [e-mail]
Subject: Questioning ethics at computing sites

I write this commentary on ethical issues concerning the dissemination
of information about the existence of viruses and how to get rid of
them as both an employee of the University of Michigan and as a
concerned member of the UM community.  The following scenario
describes the events leading up to my questioning the ethicality of
the procedures (or more appropriately, the lack of procedures) here.
Finally, I ask for comments and suggestions (e.g. how informing the
public is done at your institution) with hopes that the UM policy
makers are listening.

  I recently joined the ranks of the many computer experts employed at
the University of Michigan.  About 1 month after I started working
here, I became familiar enough with downloading Mac files from a
public file to notice that there was a new version of Disinfectant.  I
downloaded it and noticed the report of the WDEF virus.  I checked my
personal disks as well as the school owned disks in my public lab ---
all were infected with the WDEF virus.  I sent an e-mail message to
the online_help people (most of which are student "consultants"),
asking them what was to be done.  It was apparent from the response,
that the virus had been here such a short time (a few days?) that no
one was doing anything yet.  I expected a public announcement of some
sort informing users that they may be infected and that they run the
risk of being infected when they use the UM public facilities.  No
announcement was made.  Furthermore, as a specialist employed to
preside over a public computing facility (most of the computers are
Macs), I expected to be both informed that there was a new virus as
well as instructed what to do about it I heard nothing.  Two weeks
after the WDEF virus hit UM, most users were still not aware of it.  I
sent an e-mail message to my most immediate contact in the Information
Technology Division expressing my concerns.  "Shouldn't the public be
informed," I asked.  I expected a response from him and hoped that he
would forward the message on to the appropriate policy makers if he
was not in the position to deal with it himself.  I have not received
a response to my message nor have I heard any public mention of the
WDEF virus.  Users continue to infect the disks in my lab and be
infected by the disks in my lab and, as far as I know, other public
facilities at the Universtiy of Michigan.  The virus persists here.
  What should be done to rid UM of the WDEF virus or of any virus for
that matter?  How does the bureaucracy at your institution handle it?
I question the ethicality of a laissez-faire attitude on viruses at
any institution.

  Jeff Spitulnik

------------------------------

Date:    Fri, 05 Jan 90 12:13:27 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: The Amstrad virus (PC)

I mentioned the Amstrad virus in a recent posting, saying that "..it
has nothing to do with Amstrad computers...". It now appears that it
does.

The original (unmodified) version of the virus contains an
advertisement for Amstrad computers.  This text was replaced by a
short message to John McAfee, when the virus was first uploaded to
HomeBase. The name appearing in my original note about the virus is
therefore not the name of the author, but instead the name of a
respected professor in Portugal.

- -frisk

------------------------------

Date:    04 Jan 90 19:04:45 +0000
From:    [e-mail] (Brian Gordon)
Subject: Re: Where to Get Mac Anti-Virals

[e-mail] (Joe McMahon) writes:
>Hi, Mike.
>
>We've set up an automatic distribution service here at Goddard. You
>can sign up by sending mail containing the following text to
>[e-mail]:
>       [...]

Assuming this is available to those of us on usenet, not just bitnet, can you
post a path to "scfvm.gsfc.nasa.gov"?  It doesn't appear to be findable from
my maps.  Thanks.

[Ed. I believe that ...!uunet!scfvm.gsfc.nasa.gov would do the trick.]

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Brian G. Gordon       [e-mail] (if you trust exotic mailers)     |
|                       ...!sun!briangordon (if you route it yourself)        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

------------------------------

Date:    Fri, 05 Jan 90 18:24:23 +0000
From:    [e-mail] (Andreas Pikoulas)
Subject: Jerusalem B problem (PC)

          Can someone tell me how do I get rid of the Jerusalem B virus
without getting rid of the infected program too?
I remember someone told me that i have to edit some specific sectors of the
disk in order to deactivate the virus.

                                   Thanks in advance
                                         A n d r e a s

Andreas Pikoulas| UUCP :{uunet|watmath|utai|garfield}!cs.dal.ca!aucs!861087a
TOWER 410       | E-MAIL       : [e-mail]
WOLFVILLE-NS    | Phone(voice) : [phone]
CANADA  B0P 1X0 | ------- IF YOU CAN'T CONVINCE THEM, CONFUSE THEM. --------

------------------------------

Date:    05 Jan 90 17:26:20 +0000
From:    well![e-mail] (RSA Data Security)
Subject: Re: Authentication/Signature/Checksum Algorithms

In response to Y. Radai's post:

To protect against viruses, the best protection can be obtained by
using a fast hashing algorithm together with an assymetric
cryptosystem (like RSA).  This is also by far the most cost-effective
(based on compute-time) approach.

A good "message digest" should be a one-way function: it should be
impossible to invert the digest and it should be computationally
infeasible to find two useful messages producing the same digest in
any reasonable amount of time.  The algorithm must read every bit of
the message.  Therefore, the best one is the fastest one deemed to be
secure.  This should not be left to individual users to develop as
Jeunemann and Coppersmith, among others, have shown that this is not
a trivial undertaking.  Let's use Snefru and MD2 (Internet RFC 1113)
as examples of good ones.

The digest attached to a program or message should then be encrypted
with the private half of a public-key pair.  What is the
computational cost of enhancing this process with public-key?

Since RSA can be securely used with small public-key exponents such
as 3 (see Internet RFC's 1113-1115 and/or CCITT X.509) a small number
of multiplies is required to perform a public-key operation such as
*signature verification*, where one decrypts an encrypted digest with
the public key of the sender (and then compares it to a freshly
computed digest).  Therefore, the "added" computational cost of using
RSA on an AT-type machine is approximately 80 milliseconds (raising a
512-bit number to 3 mod a 512 bit number) REGARDLESS of the size of
the file being verified (the digest is fixed, and less than 512 bits,
requiring one block exponentiation).  Of course the 80 ms gets
smaller on faster machines like Suns.  I think anyone would agree
that that is a fair tradeoff for signer identity verification.  Since
one "signs" files only once, this "cost" is irrelevant.  The cost of
verifying, over and over, is what is important.

So what do you get for your milliseconds? You always know the source
of the digest (and you get non-repudiation, providing an incentive to
signers to make sure programs are clean before signing them).  No one
can change a program and recalculate the digest to spoof you.  If
schemes like this became widespread, the lack of signer
identification would be a hole people would quickly exploit.  You
also get a secure way to *distribute* software over networks.  Pretty
hard to do if everyone "does their own thing".  The Internet RFC's,
if widely adopted, provide a perfect mechanism for this.

Regardless of the hashing algorithm employed, there are powerful
benefits available if RSA is used with it.  And the computational
cost is negligible.

It may be true that simpler methods are adequate for some people.
That determination requires a risk analysis, and people will make
their own decisions.  It has been shown, however, that if a system
can be defeated, it will be.  Certainly secure software distribution
requires something more than an unprotected hash, since keys will
presumably not be shared.  This is where public-key has the most
value.

Using X9.9 is OK if (1) you trust DES (2) can live with its speed,
and (3) don't need to distribute trusted software in a large network.
X9.9 key management becomes a serious problem in a network like the
Internet.  It does have the advantage of being a standard, but it was
developed for a relatively small community of wholesale banks, not
large networks.  Note aboput standards: RSA was named as a supported
algorithm in the NIST/OSI Implementor's Workshop Agreements (for
strong authentication, in the Directory SIG) of December 1989.

Jim Bidzos
RSA Data Security, Inc.

------------------------------

Date:    05 Jan 90 20:07:02 +0000
From:    [e-mail] (Kelly Goen)
Subject: Re: Virus Trends (and FAXes on PCs)

[e-mail] (Ralph A. Shaw) writes:
>[e-mail] says:
>
>>     - A FAX message is a bitstream interpreted by an interpreter at
>>       the receving end.  Could it be induced to do something interesting
>>       through the use of illegal bit patterns?  Group III is probably too
>>       simple to be attacked, but group IV?  Imagine a message which
>>       causes a FAX machine to send an extra copy of transmitted documents
>>       to another location.
>
>Something that has come to the attention of security paranoids here
>lately is that some manufacturers of PC FAX boards have added a
>feature that allows the FAX modem to be used as a bisync modem to
>communicate with the PC directly, rather than transmitting just FAXes.
>
>I assume the PC would have to be running some software to enable it
>and reassign the console (requiring local intervention), but a
>networked PC could then prove to be a leak onto the corporate network,
>(or at least, for handy distribution of the Trojan-of-the-month program).
>Added to this is the promise that at least one FAXboard vendor
>promises that both async and bisync modem capability will be available
>in the future.

- -I would have clipped more of this but this is a complex subject that merited
serious consideration unlike the infamous modem virus scare of 1988....
actually while a receiving process has to be available on the machine to
be infected(i.e. either the legitimate file transfer program
 or a masquerading process
using this as a means to load further extensions of itself)...the important
point to remember here is that g-3 and g-4 fax formats are from what some of
techs have told me on alt.fax are internally, modified dialects of HDLC
so in this case it is possible that a sufficiently sophisticated infectious
process could use this as a pipeline to load further updates to code...
(i.e. new ways to defeat anti-viral nostrums) I will post ISBN numbers
on the protocol definitions when they finally arrive...as to whether this is
a probable scenario... who knows
   cheers
   kelly
p.s. AS I dont want to cause anyone unecessary worry let me remind all
once again that a receiving process HAS to be on the receiving machine
if it is not the legitimate File XFER program then it is illegitimate
in any case....the point that I am trying to clarify that while
an infectious process could use this as a conduit to an ALREADY EXISTING
infected host... unless there is a way to force execution of the received
code then your virus will lay dormant(i.e.nonexecutable) because of some
fax type file extension on msdos...typically something like .FAX .PIC .PCX
etc....get the picture??? on *nix type systems the problems faced
by the theoretical COMPUTER/FAX-MODEM infectious process are simpler in some
ways but require even more cooperation from receiving processes...

------------------------------

Date:    Fri, 05 Jan 90 17:12:07 -0500
From:    "Chris Khoury (Sari's Son)" <[e-mail]>
Subject: Alternative Virus Protection (Mac)

      Is there any alternative virus protection, detection init/cdev
besides vaccine and gatekeeper? I need to save space on my disk, so
gatekeeper is too large, but vaccine does not protect me disk from
the other virus's besides Scores and nVir. Any suggestions? I would
prefer that the program is shareware/PD.

    Chris Khoury
Acknowledge-To: <3XMQGAA@CMUVM>

------------------------------

Date:    03 Jan 90 22:59:29 +0000
From:    [e-mail] (Edwin Wiles)
Subject: Murray's Theorems (Was Re: Spafford's Theorems)

            [e-mail] writes:
>
>1. The amount of damage to data and availability done by viruses to date
>has been less than users do to themselves by error every day.

Granted.  However, self-inflicted damage is generally recognized much sooner,
and is often much easier to repair.  Perhaps more time consuming, but easier
because the user generally needs no special tools that he does not already have
.

>6. The current vector for viruses is floppy disks and diskettes, not
>programs.  That is to say, it is the media, rather than the programs,
>that are moving and being shared.

This is not entirely so.  There have already been cases where programs were
used as Trojan Horses to initiate viral infections.  Thus, the floppy is not
the only vector.

True, a floppy is most often used to pass the program, but that will not always
be the case.  Already, services like Compu$serve are used for exchange of
programs.  Fortunately, the sysops (at least of the amiga groups) test uploaded
software before allowing general access to it. However, such testing cannot be
perfect.

Consider a viral vector designed not to infect anything at all until a certain
date is reached, then the virus is 'quiet' until yet another date has passed.
If the vector is passed only in binary form, the chances of discovering the
virus before the vector has widely spread is quite small.  Especially if the
date that the vector starts infecting is more than 30 days in the future.

Binary only distributions are quite common, especially with the advent of
shareware.  The catch is, the designer must make the item sufficiently
usefull/interesting to get the user to download it, and then to keep using it
until the infection start date has passed.  If he is able to do that, it is
highly likely that the designer would get greater pleasure out of praise for
the inital tool!  The greater danger is a designer who modifies the binary
received from some other source.  Modification taking less effort than
ground-up design/code/test.  This would even be prefered if you wished to
destroy the reputation of the original tool designer!

Gack!  A whole new reason for paranoia!
        "Who?... Me?... WHAT opinions?!?"       | Edwin Wiles
    Schedule: (n.) An ever changing nightmare.  | NetExpress, Inc.
  ...!{hadron,sundc,pyrdc,uunet}!netxcom!ewiles | 1953 Gallows Rd. Suite 300
       [e-mail]        | Vienna, VA 22182

------------------------------

Date:    07 Jan 90 19:46:35 +0000
From:    [e-mail] (Greg Ford)
Subject: Implied Loader 'Pack' Virus (Mac)

Does anyone know what this is?  Last night, while using SUM's Tune-up
option to clean up my HD, a dialog box popped up from GateKeeper Aid
saying "Gatekeeper Aid has found and removed the Implied Loader 'Pack'
virus from the PIC file on the Games Disk".  (Games disk being one of
my partitions).  When I clicked ok in the dialog box, the dialog
immediately reappeared with the same message.  It took about 30 clicks
in the ok box for the dialog to go away (reappearing everytime).  On
top of all that, there is no file called PIC on my HD.

Any clues?  It said it removed it, so I'm not worried, but I haven't
heard of this "virus".  If one of you virus-basher guys need to check
this virus out, I can rummage through my backup (which I had just done
before) to try and find it.

Greg

*******************************************************************************
* Greg Ford                             GEnie:    G.FORD3                     *
* University of Southern California     Internet: [e-mail] *
*******************************************************************************

------------------------------

Date:    07 Jan 90 03:38:01 +0000
From:    [e-mail] (Woodrow Baker)
Subject: Re: Virus Trends (and FAXes on PCs)

[e-mail] says:
>     - A FAX message is a bitstream interpreted by an interpreter at
>       the receving end.  Could it be induced to do something interesting
>       through the use of illegal bit patterns?

Now that hard disks are available on Postscript printers, We have
another problem.. It is concievable to embed a virus, or a trojan in a
font.  If the font were encrypted, it would be mighty hard to hunt the
virus down.  It could convievably alter fonts on the hard disk, screw
up font chache images, and or plain crash the hard disk.  It would,
however be difficult for it to infect other systems, unless one
retrieves a contaminated file and sends it to another laser printer.
The potential for abuse also exists in prolouges.  I have not seen or
heard of one yet, but now is the time to give some thought to how to
prevent them BEFORE they start getting out of hand.

Cheers
Woody

p.s.  Some of the new VIDEO cypherrs are viruses of a sort.  They play
with the signal to screw-up VCR's.  Messing with the Automatic Gain
control among other things.  If some one manages to overcome them, and
make a copy of the tape, the messed up signal could sort of take on
viral properties, though they would not do any damage.

------------------------------

Date:    07 Jan 90 04:18:00 +0000
From:    [e-mail] (Charlie Lear)
Subject: Re: Viruses Rhyme And Reason

[e-mail] (Bill Weston) writes:
>I'm not sure that writing viruses will ever stop.
>
>Ross Greenberg wrote perhaps the best psychological profile of the
>"virus programmer" that I have ever read.  (It's in the docs of
>FLUSHOT, you've all read it...)
>
> The virus writer likes causing damange.  He thinks it's funny and makes him
>feel powerful.
> To this day, tha STONED virus still infects thousands of systems all over the
>world.  (Poorly written as it is..)
>
>The target of many virus writers are the millions of PC users who don't know
>much about computers.  The novice user, or perhaps the user who knows how to
>run programs but does not know much about DOS, is the primary mark.  A friend
>of mine was just such a person.  Less than 20 days after buying his PC he was
>hit by the STONED virus.  He did not know how to protect himself.  Lots of
>grins for the programmer.

One day, you'll actually write something you know something about,
Bill... 8-)

The schoolkid who wrote the Stoned virus did it on a dare from an
Amiga owner who was suffering from the first effects of the SCA virus.
It was believed *impossible* by the "experts" for a PC virus to be
written, so he went ahead and wrote a simple, non-destructive bsv on a
standard XT.  Having written it, the consequences of unleashing it
became a bit much to think about, so he made sure all copies were
destroyed bar one which he kept at his house.

Despite being under lock and key, his little brother and a couple of
his friends thought it would be a huge joke to steal the disk and
deliberately infect disks in a local computer store.  This was fine,
but after the initial laffs it proved impossible to trace ALL infected
disks and the STONED epidemic was born.

Since then, the programmer has lived a very cloistered, paranoic life.
Huge publicity has done nothing to help his studies or his state of
mind, even though his identity has not been publicly revealed.  The
last burst of publicity was later discovered to be a protection
mechanism for the guy, although front page coverage on a capital city
daily is bizarre protection.

It seems that after the "blue" side in an Australian army exercise
deliberately infected "red" side computers with the virus to gain
military advantage, certain people in certain security organisations
wished to interview the man who wrote Stoned.  The press coverage
allegedly stopped a kidnap attempt in its tracks - the threat of a
full diplomatic incident was too much for the Aussies and they went
home.

Of course, I have no documentary proof of the above as anyone
connected with the writing or dissemination of a virus would be stupid
to write anything down.  I believe I have just illustrated how an
"innocent" prove-it-can-be-done scenario can turn unbelievably bad.
Is it really the programmers fault that the virus does not damage 360k
floppies or 20meg XT disks, and only becomes a danger when used on
large capacity floppies or big hard disks?  He had no access to, or
knowledge of, such hardware when he wrote it...

- --
Charlie "The Bear" Lear: Call The Cave BBS, 64(4)643429 157MB Online!
Snail: P.O. Box 12-175, Thorndon, Wellington, New Zealand

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Tuesday,  9 Jan 1990    Volume 3 : Issue 7

Today's Topics:

public trust vs. viruses
Partial VIRUSREM PACKAGE (Mac)
Implied Loader Viruses (Mac)
F-PROT anti-virus program (PC)
Re: Questioning ethics at computing sites
Virus Scare & Backups
Jerusalem B Virus Remover (PC)
Re: Alternative Virus Protection (Mac)
Re: Virus Trends (and FAXes on PCs)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

---------------------------------------------------------------------------

Date:    Mon, 08 Jan 90 09:46:00 -0500
From:    [e-mail]
Subject: public trust vs. viruses

>As Mr. Murray correctly pointed out, much more users damage their own
>data than are damaged by 'nasty' software.  The Oct 13 scare made our
>users, who number in the tens of thousands,  FINALLY listen to our
>pleadings to make backup copies of their software and data.

That a lie happens to result in some behavior that you favor, does not
make it any less a lie.  While it may be true that the publicity did
result in a temporary increase in backup behavior, the benefit of such
behavior may not be in proportion to the damage to public trust.

William Hugh Murray, Fellow, Information System Security, Ernst & Young
2000 National City Center Cleveland, Ohio 44114
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840

------------------------------

Date:    Mon, 08 Jan 90 09:24:04 -0500
From:    Joe McMahon <[e-mail]>
Subject: Partial VIRUSREM PACKAGE (Mac)

It seems that some nodes are refusing parts of the virus removal
package because of file size constraints (100K max). We are looking
into the problem. Anyone currently signed up for the package will
receive the rest of the files as soon as we have determioned the best
way to redistribute them. Thanks for your patience.

 --- Joe M.

------------------------------

Date:    Mon, 08 Jan 90 10:46:04 -0500
From:    Joe McMahon <[e-mail]>
Subject: Implied Loader Viruses (Mac)

Any resource which appears to be of an executable type which is found
in a "non-application" file will be flagged as an "implied loader".
You may have an invisible file called "PIC". Try looking at your disk
with ResEdit or DiskTop.

 --- Joe M.

------------------------------

Date:    Mon, 08 Jan 90 15:47:00 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: F-PROT anti-virus program (PC)

As some of you already know, I have been working on an anti-virus
package the last five months or so.  The English version of this
package, F-PROT, is now (finally) ready for distribution. It can
handle the following PC viruses:

    Agiplan, Alabama, Alameda (Yale), Amstrad, April 1., Brain, Cascade,
    Dark Avenger, DataCrime, DataCrime II, dBase, December 24th, Den Zuk/Ohio,
    Disk Killer (Ogre), Do-Nothing, 405, 4096, Fumble, Fu Manchu, Ghost,
    Icelandic/Icelandic II/Saratoga, Jerusalem/New Jerusalem/Sunday,
    Lehigh, MIX1, New-Zealand (Stoned), Oropax, Perfume, Ping-Pong/Typo,
    South African "Friday 13.", Sylvia, SysLock/Macho, Swap (Fallboot),
    Traceback/2930, Vacsina, Vcomm, Vienna/Lisbon, Virus-90, W13, Yankee
    Doodle and Zero Bug (Palette)

Included in the package are programs for...

   ... scanning diskettes or files for infection (similar to SCAN and
       VIRSCAN)

   ... removing any viruses found without destroying the original programs
       (a complete set of disinfection tools)

   ... preventing infected programs from being executed (similar to SCANRES)

   ... adding "self-testing" to other programs

   ... providing protection against Trojans

and much, much more...

The programs included are even able to prevent the use of Dr Solomon's
"fourth method".

When new viruses appear, only a single tine, containing an encrypted
signature string has to be added to one of the text files.

The package will be distributed as shareware, (suggested contribution
$15 US).

The .ARC file is rather large (237K), but I will arrange for it to be
uploaded to SIMTEL and the various anti-virus archives. I intended to
have the program distributed on comp.sys.ibm.pc, but the resignation
of the moderator there will probably delay that.

I will also E-mail copies to those I have already promised a copy, but
I simply cannot send copies to everyone interested.  However, if you
are willing to upload the package to a BBS or make it available to a
number of other people, let me know and I'll E-mail you a copy.

I will send the package as a XXencoded PKarc file. If you do not have
xxdecode, I can include the source to it (in C).

- -frisk

------------------------------

Date:    Mon, 08 Jan 90 10:08:25 -0600
From:    "McMahon,Brian D" <[e-mail]>
Subject: Re: Questioning ethics at computing sites

[e-mail] tells us of inaction at his institution
upon discovery of a widespread WDEF infestation, and asks:

>  What should be done to rid UM of the WDEF virus or of any virus for
>that matter?  How does the bureaucracy at your institution handle it?
>I question the ethicality of a laissez-faire attitude on viruses at
>any institution.

While I am unfamiliar with the bureaucracy at U. Mich., it certainly
appears to me that Jeff has made a reasonable, good-faith effort to
gain attention through the usual channels, and has been stone-walled.
Rather than speculating as to why, the first priority should be to
protect users from further damage.  You need a campaign of public
education, and you need it yesterday.

I would suggest starting with the student consultants you mentioned in
as online_help receivers.  Give them the tools to detect, remove, and
prevent WDEF (Disinfectant 1.5 with either GateKeeper Aid 1.0.1 or
Eradicat'Em 1.0) and have them put the word out.  If there is another
staffer who is responsible for the students, it may be advisable to go
through him first.  Logon messages, signs in public Mac labs, and
newsletter articles are other possible channels.  Be sure to emphasize
that there's no immediate cause for panic, only prudence.

As for the ethical question ... In my personal opinion, KNOWINGLY
allowing unsuspecting users to contract infections is EXTREMELY
irresponsible.  The question is, is the threat really "known" to the
bureaucracy, or is this a case of "not my department?"  If you have a
co-ordinator of micro labs (or some such position), I might suggest a
review of anti-viral procedures ...

Brian McMahon  <MCMAHON@GRIN1>
Programmer
Grinnell College
Grinnell, Iowa 50112
[phone]

My own opinions, of course . . .

------------------------------

Date:    Mon, 08 Jan 90 14:27:00 -0400
From:    Norman <[e-mail]>
Subject: Virus Scare & Backups

> However, I really think that there was a major benefit to all of this [media
> hype over virus scare]
> ...
>The Oct 13 scare made our users [...]FINALLY listen to our pleadings
>to make backup copies of their software and data.

Interesting...where I work (NOT York U, by the way), we had just the
opposite happen.  Since there was no apparent danger from the virus,
there's obviously no need for backups.  This belief is somehow
supported by the fact that all 300+ computers in our building and
remote offices survived the scare. (I won't mention the belief by some
that the virus affected IBM labelled computers ONLY).

And no amount of pleas or lecturing will get them to change.  The only
thing that seems to have an affect is when somebody drops a PC and
trashes a hard disk in the process (and believe me, it's happened more
than once).

Norman
[e-mail]                    [e-mail]
[e-mail]

Not connected to York U (I'm just a student). Standard disclaimers apply.

------------------------------

Date:    Tue, 09 Jan 90 09:18:53 +0000
From:    [e-mail]
Subject: Jerusalem B Virus Remover (PC)

In reply to Andreas Pikoulas; Virus-l vol3 no.6:

I have recently downloaded a program that heals/removes this virus.
It is available from:
                      WSMR-SIMTEL20.ARMY.MIL
           directory: PD1:<MSDOS.TROJAN-PRO>
                file: M-JRUSLM.ARC

Use anonymous FTP to gain access to the server.

                 Bob.Gowans
- -----------------------------------------------------------------------------
JANET:       [e-mail]
Internet:    [e-mail]     Dept Civil Eng,
EARN/BITNET: R.Gowans%MCC.ac.uk@UKACRL              U.M.I.S.T,
UUCP:        ...!ukc!umist!R.Gowans                 Sackville Street,
                                                    Manchester.
FAX:         [044 61  | 061] 200-4016               M60 1QD.

------------------------------

Date:    09 Jan 90 16:31:43 +0000
From:    munnari!insted.unimelb.edu.au![e-mail] (Lord Vader)
Subject: Re: Alternative Virus Protection (Mac)

[e-mail] (Chris Khoury (Sari's Son)) writes:
>       Is there any alternative virus protection, detection init/cdev
> besides vaccine and gatekeeper? I need to save space on my disk, so
> gatekeeper is too large, but vaccine does not protect me disk from
> the other virus's besides Scores and nVir. Any suggestions? I would
> prefer that the program is shareware/PD.
>
>     Chris Khoury
> Acknowledge-To: <3XMQGAA@CMUVM>

Have considered RWatcher?  It is configurable.  It can be found with
all the other virus stuff at your friendly neighbourhood ftp outlet
that stocks mac stuff, or just go straight to SUMEX and dont pass go
:)

- --
George Stamatopoulos                                    #### ###
La Trobe University -                                   #### ###
        Lincoln School of Health Sciences               #### #####
Computing Unit                                          #### ##### incoln
Melbourne                                               ####
Victoria                                                ##########
Australia                                               ########## a Trobe

------------------------------

Date:    Tue, 09 Jan 90 01:13:07 +0000
From:    [e-mail] (Geoffrey H. Cooper)
Subject: Re: Virus Trends (and FAXes on PCs)

[e-mail] (Ralph A. Shaw) writes:
>[e-mail] says:
>
>>     - A FAX message is a bitstream interpreted by an interpreter at
>>       the receving end.  Could it be induced to do something interesting
>>       through the use of illegal bit patterns?

One annoying thing you can do is to spew out paper from the remote fax.
The protocol allows the paper length to be anything up to (i think) 65K
lines or so, so you could spew out 25' of paper at a time, finishing
the receiver's roll of paper and so rendering it useless.  Note that
it doesn't take much time to transmit this image, if it is toally
white or black.

- - Geof
- --
[e-mail] / aurora![e-mail] / [e-mail]

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Wednesday, 10 Jan 1990    Volume 3 : Issue 8

Today's Topics:

SCANV55 and CLEANV55 (PC)
Re: Authentication/Signature/Checksum Algorithms
New anti-virals uploaded to SIMTEL20 (PC)
WDEF A (Mac)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

---------------------------------------------------------------------------

Date:    Tue, 09 Jan 90 10:57:18 -0800
From:    [e-mail]
Subject: SCANV55 and CLEANV55 (PC)

SCANV55 has been released.  IT is able to detect the 4096 virus in
memory prior to doing a scan.  The 4096 is similar to the Dark Avenger
in that it infects every executable file that is opened.

CLEANP55 (Clean-Up) is also now available on HomeBase.  It's the
shareware equivalent of the VirClean commercial program (from Hirst
and McAfee).  Clean-Up uses I.D.'s displayed by SCAN55 to determine
which virus to check for and remove.  It repairs the infected programs
and returns the system to normal in most cases.  Clean-Up now replaces
all of the individual disinfectors that had been available on
HomeBase.  About time!

Alan

------------------------------

Date:    Tue, 09 Jan 90 16:40:42 -0800
From:    [e-mail] (duncs home)
Subject: Re: Authentication/Signature/Checksum Algorithms

In article <[e-mail]> you write:
>In response to Y. Radai's post:
>
>To protect against viruses, the best protection can be obtained by
>using a fast hashing algorithm together with an assymetric
>cryptosystem (like RSA).  This is also by far the most cost-effective
>(based on compute-time) approach...

With this scheme, what prevents a clever nasty from simply patching
the code doing the comparison to always return an all clear?  Also,
while the non- repudiation property seems to provide accountability,
it seems likely to be illusory.  Does the signer of the program really
know what's being signed or was it generated by some other program of
uncertain honesty?
                                --Dunc

------------------------------

Date:    Tue, 09 Jan 90 22:28:00 -0700
From:    Keith Petersen <[e-mail]>
Subject: New anti-virals uploaded to SIMTEL20 (PC)

I have uploaded the following files to SIMTEL20:

pd1:<msdos.trojan-pro>
NETSCN54.ARC    Network compatible - scan for 60 viruses, v54
SCANRS54.ARC    Resident virus infection prevention program
SCANV54.ARC     VirusScan, scans disk files for 60 viruses

These programs where downloaded from the Homebase BBS.

- - --Keith Petersen
Maintainer of SIMTEL20's CP/M, MSDOS, & MISC archives [IP address 26.2.0.74]
Internet: [e-mail], [e-mail]  BITNET: w8sdz@NDSUVM1
Uucp: {ames,decwrl,harvard,rutgers,ucbvax,uunet}!wsmr-simtel20.army.mil!w8sdz

[Ed. As always, a hearty Thank You, Keith!]

------------------------------

Date:    10 Jan 90 00:48:04 +0000
From:    salamon <@sun.acs.udel.edu:[e-mail] (Andrew Salamon)>
Subject: WDEF A (Mac)

I hope I am not saying something that everyone already knows about,
but Newark Hall is infected with the Mac virus WDEF A.  It is a very
infective virus.  I took my work disk home inserted it into my mac
Plus and then went to open Disinfectant and by the time I ran it my
hard drive was infected, and I'm sure it wasn't infected before.

Even if it doesn't do any damage (am I right about this?) I find that
to be very obnoxious.

       **  **                          |   /Andrew/
         /\       HAVE A NICE DAY!     |   self-styled Bleydion op Rhys
       \____/                          |   [e-mail]
                                       |

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Thursday, 11 Jan 1990    Volume 3 : Issue 9

Today's Topics:

An interesting article (Gen'l)
Shrink Wrap...still safe?
Re: Questioning ethics at computing sites
10th Annual Conference
SCANV55 (PC)
Harddisk destroying virus ?? (Atari ST)
WDEF (Mac)
Fractal Virus Alert! (PC)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

---------------------------------------------------------------------------

Date:    Wed, 10 Jan 90 12:31:37 -0500
From:    [e-mail] (David Gursky)
Subject: An interesting article (Gen'l)

I am told that in the November '89 issue of the American Mathematical
Monthly, to the effect that no completely safe computer virus test is
possible.  The proof is suppose to be short, and along the lines of
the various proofs of the Halting problem.

------------------------------

Date:    Wed, 10 Jan 90 00:00:00 +0000
From:    "Craig W. Fisher" <[e-mail]>
Subject: Shrink Wrap...still safe?

At a meeting yesterday some people made comments that some viruses
have been found in shrink-wrapped diskettes.  This did surprise me as
we have been using a rule of thumb to stick to shrink wrapped software
to help avoid viruses.  What comments &/or advice do you have for this
situation?
       Thanks, Craig

PS: I almost typed shrink warpped...interesting freudian slip!
Acknowledge-To: <JZH1@MARISTB>

------------------------------

Date:    Wed, 10 Jan 90 20:45:06 +0000
From:    [e-mail] (Steven Falkenburg)
Subject: Re: Questioning ethics at computing sites

[e-mail] writes:

[stuff deleted]
>It was apparent from the response,
>that the virus had been here such a short time (a few days?) that no
>one was doing anything yet.  I expected a public announcement of some
>sort informing users that they may be infected and that they run the
>risk of being infected when they use the UM public facilities.  No
>announcement was made.  Furthermore, as a specialist employed to
>preside over a public computing facility (most of the computers are
>Macs), I expected to be both informed that there was a new virus as
>well as instructed what to do about it I heard nothing.  Two weeks
>after the WDEF virus hit UM, most users were still not aware of it.  I
>would forward the message on to the appropriate policy makers if he
>was not in the position to deal with it himself.  I have not received
>a response to my message nor have I heard any public mention of the
>WDEF virus.  Users continue to infect the disks in my lab and be
>infected by the disks in my lab and, as far as I know, other public
>facilities at the Universtiy of Michigan.  The virus persists here.
>  What should be done to rid UM of the WDEF virus or of any virus for
>that matter?  How does the bureaucracy at your institution handle it?
>I question the ethicality of a laissez-faire attitude on viruses at
>any institution.
>
>  Jeff Spitulnik

As a Macintosh support person and programmer for the Computer Aided
Engineering Network at the University of Michigan, I think I should
try to clarify the response by U of M to the WDEF virus crisis.

The University of Michigan has two major computer support
organizations: the Computer Aided Engineering Network (CAEN) provides
support for the Engineering students and faculty, while the U of M
Computing Center (several organizations under the Information
Technology Division) provide computing support to the rest of the
University.

As one of the first sites in the country to be hard-hit by the WDEF
virus, we at CAEN acted immediately by searching out possible
solutions to the virus.  Virtually every CAEN lab mac was infected
(about 160 hard disks).  The virus was first disassembled by a member
of Mac Support, and another employee tailored one of the virus removal
patches (the one written by Juri Munkki (sp)) to meet our needs.  This
vaccine was then installed on all of the lab machines, and copies of
Disinfectant 1.5 were put on the lab software servers.  We then put
notices in the labs and an article in our newsletter.  All of this
action occured within 1 week of our discovery of the WDEF virus, and
we are now protected from it.

I can't speak for the Computing Center's public facilities sites, as
we are in a different unit of the university.  We did give them a copy
of our modified WDEF vaccine, but they chose not to use it, as far as
I know.

In other words, the entire University was not ignoring the problem, as
the previous poster implies.  We believe we now have the tools in
place to deal with new viruses which will inevitably infect our
Macintosh computers.

Steven Falkenburg ([e-mail])
Computer Aided Engineering Network
University of Michigan, Ann Arbor

[Ed. This again raises an interesting point: how are other
Universities and organizations equipped to respond to and/or prevent
virus infections?  Anyone from groups with policies in place for these
things care to comment?]

------------------------------

Date:    Wed, 10 Jan 90 16:25:00 -0500
From:    MIS Training <[e-mail]>
Subject: 10th Annual Conference

CALL for speakers at MIS TRAINING INSTITUTE
         10th Annual Conference on Control, Audit & Security of
         IBM Systems

Oct. 1-4, Washington, DC.

This conference is geared toward EDP Auditors, Information security
professionals and DP personnel involved with information systems
security and control.

Subjects cover all major hardware and software platforms from the
control, audit, and security perspective.

Sessions are 90 minutes minimum and all speakers are required to
provide handout material for each session.

Please reply via email (MCI ID 243-9796), voice 508-879-7999,
FAX [phone] or USPS  498 Concord St. Framingham, MA 01701

All prospective speakers must reply by 1/31/90.

[Ed. To send email to MCI ID 243-9796 from Internet, address it to
[e-mail].]

------------------------------

Date:    10 Jan 90 23:22:13 +0000
From:    [e-mail]
Subject: SCANV55 (PC)

     This is my first post to this or any group within this system.
     The information I have seen here has been very usefull and I
     look forward to keeping in touch with this group.

     I would like to know of a PUBLIC BBS in the US which has SCANNV55
     and CLEANV55 for download.  If anyone can help me, please let me
     know.  Thank you...

     Michael -

[Ed. Try the HomeBase BBS at - [phone]]

------------------------------

Date:    11 Jan 90 14:31:55 +0000
From:    [e-mail] (Erwin d'Hont)
Subject: Harddisk destroying virus ?? (Atari ST)

A friend of my told me that there is a Virus lose that has a certain
effect on the harddisk attached to your atari st. It would have the
ability to make the drivehead of your harddisk make a 'headcrash'.
Has anyone had some experiences with this virus ????

Erwin

------------------------------

Date:    11 Jan 90 14:05:19 +0000
From:    James Cayz <[e-mail]>
Subject: WDEF (Mac)

Sounds like those machines need some Eradicat'Em.  All of the normal
Internet Mac Archive sites have it on-line by now.  If you can't get
it from there, or the MRC, gimme a yell (x6307 (if no answer try
x2335)), but it may take a few hours (maybe a day) for me to get it to
you.

Does anyone know of a combination Vaccine / Eradicat'Em init (ie,
catches everything) that doesn't need a lot of work to set up (ie,
like GateKeeper / GK Aid) ?

James

|James Cayz can be found via:    USPS: Educational Technology Laboratory,
|E-MAIL (ARPA): [e-mail]  : 203 Willard Hall Education Building,
|PHONE: [phone]              : University of Delaware, Newark DE 19716

------------------------------

Date:    Thu, 11 Jan 90 11:19:25 -0500
From:    [e-mail]
Subject: Fractal Virus Alert! (PC)

VIRUS ALERT:  IBM-compatible personal computers
The Vector:  THE DESKTOP FRACTAL DESIGN SYSTEM  (Michael F. Barnsley)

The Desktop Fractal Design System by Michael F. Barnsley, Iterated Systems,
Inc. (1989) is infected with a virus.  The program is sold through Academic
Press and is a companion program to Barnsley's textbook on fractals,
"Fractals Everywhere".  Academic Press is aware of the problem, and will
replace the distribution disk with a clean copy if you return it to them.

The virus does not seem to attach itself to the operating system, but
increases the length of every .EXE file run after an infected program
has been run.  The only .EXE file whose length does not increase is the
vector, SAT.EXE, the main program of The Desktop Fractal Design System.

Other symptoms include displacement of blocks of text on the screen
and total disruption of asynch communications.  I have also seen
"Stack overflow" errors in dBASE since I installed the infected
program.  I do not know if there are more serious delayed effects.

I assume that this was an accidental infection before the program
left Iterated Systems.  I don't know whether Academic Press is making
any effort to contact people who have purchased the program.
It's a great program, and probably a lot of people will pass copies
to their friends.  Watch out for it!

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Thursday,  1 Feb 1990    Volume 3 : Issue 29

Today's Topics:

Re: Universal virus detector
Removing the 4096 (PC)
Re: Security and Internet Worms (Source Code)
Statistical Distributions and Virus Spreading
JERUSALEM B again (PC)
Re: Gatekeeper veto: Normal behavior or virus attack?
Re: Virus Modeling
Re: 'Virus request' from Taiwan
WDEF A & B hit Oregon State University
Re: 4096 and 1260 Viruses (PC)
WDEF in Illinois (Mac)
VAX Virus request update (general)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

---------------------------------------------------------------------------

Date:    Wed, 31 Jan 90 13:13:00 -0500
From:    [e-mail]
Subject: Re: Universal virus detector

David Chess asks how my hardware timestamp forms a universal virus
detector.  He misses the point of my message.  I wasn't trying to
define a good user interface to such a system; I was only sketching
out how the hardware might work.

Any creation or modification of executable code on a system is either
desired or undesired.  You first of all have to be able to distinguish
between those two possibilities.  The distinction is based on the
intent of the operator, so is not amenable to mathematical argument as
such.

While it may sometimes be difficult to decide exactly what catagory
some transitions fall into, in many cases I can be definitive.  In
particular, there it is almost always the case that no existing
executable should be modified, ever.  All my existing executables can
be checked by comparing their timestamps with known-correct values.
Think of this as a very cheap, absolutely unforgeable checksum.

More generally, any time I am certain my system is "clean" I can
generate and save on a secure medium a list of all timestamps on my
disk.  Any time later, I can generate a new list and compare.  It is
then up to me to decide whether any differences that show up are
legitimate - but I have the absolute assurance that I WILL get an
indication of any changes.

BTW, if you really want to build such hardware you can easily go
further, in several ways.  For example, you can add a
hardware-enforced switch which when in the OFF position makes it
impossible to set the "is executable" bit at all.  In this mode, you
can't do program development, install new executables, or even copy
executable files - but you absolutely can't be infected either.  The
vast majority of systems could probably spend most of their time with
the switch in this position.

Another alternative is to add another bit, the "may create
executables" bit.  Only code running from a block marked with this bit
may turn on the "executable" bit for another block.  Normally, only
the linker and an image copier would have this bit set.  A virus could
still be written - but it couldn't modify existing code directly, it
would have to produce object code and pass it through the linker.

There are certainly some fundamental issues in dealing with viruses,
but most of the PRACTICAL issues are the direct result of PRACTICAL
hardware and software design decisions.
                                                                      -- Jerry

------------------------------

Date:    Tue, 30 Jan 90 15:12:09 +0200
From:    "Yuval Tal (972)-8-474592" <[e-mail]>
Subject: Removing the 4096 (PC)

There is a very easy method to get rid of the 4096 virus (100 years).
Lets say you want this virus had spread on your hard-disk and you want
to remove it.  Take an *INFECTED* PKZIP, PKARC or any other such
thing. Compress all your files (or some of them) into one file. Erase
all the compressed files from your disk and boot from a clean
diskette. Now, take a *CLEAN* PKUNZIP, PKXARC or whatever and open the
compressed file. That's it!

How does it work??? When the virus is active in memory, and you try to
read an infected file, it will only read the file until the virus
(orinial file). So, what really happens here, is that the archiver
compresses only the files without the virus.

- -Yuval Tal

+--------------------------------------------------------------------------+
| BitNet:   NYYUVL@WEIZMANN        Domain: [e-mail] |
| InterNet: [e-mail]                        |
+----------------------+---------------------------------------------------+
| Yuval Tal            | Voice:   [phone]  (In Israel: 08-474592)    |
| P.O Box 1462         | BBS:     [phone] * 20:00-7:00 * 2400 * N81  |
| Rehovot, Israel      | FidoNet: 2:403/136                   (CoSysop)    |
+----------------------+---------------------------------------------------+
|  "Always look on the bright side of life" *whistle*  -  Monty Phython    |
+--------------------------------------------------------------------------+

------------------------------

Date:    Wed, 31 Jan 90 10:10:20 +0000
From:    Technician <[e-mail]>
Subject: Re: Security and Internet Worms (Source Code)

Having read the following:
>Yes, I believe that viral source code ought to be distributed and
>studied-but under controlled conditions.  The universities offer the
>best hope of such a controlled setting.

I for one would not reccomend this site (and I strongly suspect the
majority of other campus type sites) as a recipient or study site for
virus/worm/Trojan, or what ever comes next, sources.

Security tends to be very lax, as neither the time, money or inclination
is available to change this.

I would suggest a limited number of 'bonded sites' who do take
security seriously (which may well include many Universities)
act as co-ordinators, with the possiblilty of farming out
single problems to trusted users at less secure sites.

/ All opinions expressed here are mine and mine alone, licences
  are available for those who wish to use them.                 /

Jim Cottrell, Software Technician,
Computer Science, University of Dumham.

------------------------------

Date:    Wed, 31 Jan 90 13:50:45 -0500
From:    "Gregory E. Gilbert" <[e-mail]>
Subject: Statistical Distributions and Virus Spreading

Does virus occurence subscribe to some statistical distribution?

Q:  Suppose there is this new virus prevention/eradication software available
    for free, but there is an update policy of either $25 per update (i.e.
    configuring for new viruses) or $100 per year for an update subscription.
    Should I purchase the subscription or should I buy each update?  i. e.
    What is the probability in the next year that more than four viruses
    (strains, clones, etc....) will occur?

    Another way of asking this would be, "Is is cost effective for me to
    purchase the update subscription."

                                                Greg.

Postal address: Gregory E. Gilbert
                Computer Services Division
                University of South Carolina
                Columbia, South Carolina   USA   29208
                [phone]
Acknowledge-To: <C0195@UNIVSCVM>

------------------------------

Date:    Wed, 31 Jan 90 15:16:27 -0500
From:    "Thomas W. Stuart" <[e-mail]>
Subject: JERUSALEM B again (PC)

A faculty member here at SUNY at Buffalo has been hit by the Jerusalem B
virus brought in on a commercially purchased program.  A blurb from the
publisher/distributor suggests scanning with either "sieve" or "scan54".
and eradicating with "M-Jerusalem".

Are any of these programs available from a bitnet or internet accessible
source?  And does this advice seem sound?

Please address any responses to me directly.

Thanking you in advance,
Thomas Stuart <c078d6s6 at ubvm>
School of Information and Library Studies
SUNY at Buffalo

------------------------------

Date:    31 Jan 90 21:23:36 +0000
From:    boulder!boulder![e-mail] (JOHNSON RICHARD J)
Subject: Re: Gatekeeper veto: Normal behavior or virus attack? (Mac)

[e-mail] (Norman Swenson) writes:
] I have noticed something suspiciously virus-like on my Mac II.
...
] Fearing an imminent disk crash, I backed up my hard disk to another.
] While the files were copying over, I got a veto message from Gatekeeper.
] I decided to check my disk using Disinfectant 1.5 and found that Drawover
] (part of Adobe Illustrator) was infected with nVir B.  I disinfected that
] file, and all my disks then scanned clean.

The veto message you got probably had nothing to do with the nVIR B
infection.  (However, if you'd tried to run Drawover before disinfecting
it, you probably would have gotten a message about nVIR B.)

] However, whenever I try to open the Illustrator folder on the backup
] disk, I get the following veto message: 'Gatekeeper has vetoed an
] attempt by Finder to violate "Res(other)" privileges against Desktop.
] [AddResource(ADBS,0)]'.  I have isolated the behavior to the Adobe
] Separator 2.0 program.

Yup.  ADoBe Separator uses ADBS for it's creator signature.  Sadly, the Mac
OS also uses a resource called ADBS for the Apple Desktop BuS.  The latter
is executable code, while the signature resource isn't.  GateKeeper blocks
unprivileged attempts to add executable resources to file, and is obviously
mistaking the totally harmless signature resource for a nasty virus.
Stupid GateKeeper :-)  The solution here is to simply not use applications
that use resource names as their application signatures.  Stupid Adobe :-)

] Why would opening a folder require adding a resource to the desktop
] file?

The Finder keeps track of which icons to display for which files.  To do
that it stores the icons, signature resources, etc. in the DeskTop file.
If the Finder discovers an unknown file in a folder, it will attempt to
add that file's identifying info to the DeskTop.

] And why did Gatekeeper veto it on one disk, but not the other?

I dunno.  The Finder is often mysterious to the semi-initiated (like me).
Perhaps an expert can take the rest of the questions?

] Norm
] [e-mail]

| Richard Johnson                           [e-mail] |
|    CSC doesn't necessarily share my opinions, but is welcome to.     |
|  Power Tower...Dual Keel...Phase One...Allison/bertha/Colleen...?... |
|   Space Station Freedom is Dead.  Long Live Space Station Freedom!   |

------------------------------

Date:    Wed, 31 Jan 90 23:07:00 +0000
From:    [e-mail]
Subject: Re: Virus Modeling


[e-mail] writes:

> A co-worker of mine wrote:
>      One way to characterize a Trojan Horse or a virus is to build
>      mathematical, abstract models of them.  Such a model may be an
>      n-tuple of interrelated subjects, objects, and operations.
>      Thereafter, abstracted audit data and host machine
>      characteristics can be organized to find if all the components of
>      such an n-tuple are present.
>
> My assignment was to help with the research in attempting to come up
> with such a model.  Now, from what I have been reading on the Virus
> forum, I am wondering if this task is even possible.
> ...
> Is it possible to come up with such a model?  Is it possible to list
> ALL of the characteristics of a virus?  If so, what might these
> characteristics be?  If not, why not?
>
> David T. Opitz  - NSCS

I would estimate that such a program would be only slightly easier
than a program to pass the Turing test. As someone pointed out, a real
computer isn't a finite state machine because it includes the person
operating it (well the whole universe has a finite number of states
but we're getting way beyond anything of practical use). Therefore
there is no universal algorithm for detecting viruses a priori. How
about a non-universal algorighm that will detect a virus say 95% of
the time? I don't think that's possible either. Consider possible
countermeasures: The virus inspects a component of the operating
system or hardware (e.g. checks if files of certain names are present,
the files in question being essential components of the operating
system), and uses the result to generate a 32-bit number which it then
uses to decrypt a chunk of data which contains the infector code. It
then executes the infector code. Even a brute-force inspect all
possible execution paths approach won't work here because infection
depends on things outside the program itself .. unless you're going to
simulate the suspect program in a simulation of an entire machine
which isn't very practical. Consider: even a good human hacker would
have great difficulty finding a cunningly-hidden virus in a big
program. You're going to need something pretty close to true AI.

"To summarize the summary of the summary: people are a problem"
Russell Wallace, Trinity College, Dublin
VMS: [e-mail]
UNIX: [e-mail]

------------------------------

Date:    Wed, 31 Jan 90 12:39:00 +0000
From:    [e-mail] (Todd Hooper)
Subject: Re: 'Virus request' from Taiwan

> Date:    Thu, 25 Jan 90 12:08:35 -0500
> From:    woodb!scsmo1![e-mail]
>
> Should it be illegal to own or transmit virus source (for non-security
> personnel)??
> <etc etc>

A storm in a teacup I'm afraid. What possible technique could you use
to make it 'illegal to own or transmit virus source'? I mean, if in
the U.S.  you can buy books on homemade weapons from machine guns
right up to nerve gas and atomic bombs, I can't see the U.S.
Government being able to successfully crack down on people swapping
virus source code.

It seems to be a common practice on this newsgroup/mailing list to
assume guilt until shown otherwise. E.g. 'Morris is guilty writing the
Internet Worm', before a verdict has been handed down. Statements such
as 'Anyone who has virus source code must be a criminal' are of a
similar ilk.

[e-mail] (Dr. A. Wood) writes:

> If James Huang is Taiwanese, then his first and most familiar language
> is likely not English but Chinese, and likely he committed no computer
> ethical error but merely a language blunder, namely the common capital
> offence of 'unclear use of a pronoun'!  <WOODB!SCSMO1![e-mail]>,
> in the course of emptying his  flamethrower down the  computer link at
> the  unfortunate Huang, seems to   imply that Huang   meant "I want to
> spread VAX virus".  But Huang could also have intended to say  "I want
> to spread news about how to notice and combat VAX virus"
>
> - - which is what Virus-L is for!!

I couldn't agree more. Get off the poor guys back!

- --
Todd Hooper                                                Computing Centre
                                            Curtin University of Technology
PSImail: psi%050529452300070::CHOOPER                     Western Australia
ACSnet : [e-mail]
Bitnet : [e-mail]
UUCP   : {enea,mcvax,uunet,ubc-cs,ukc}!munnari!acad.curtin.edu.au!CHOOPER
Phone  : [phone] (24 hour messaging system) Fax [phone]

------------------------------

Date:    01 Feb 90 14:46:01 +0000
From:    [e-mail] (Mark R. Slezak)
Subject: WDEF A & B hit Oregon State University

Here at OSU we got hit with both the WDEF A & B here in our campus
lab.

 Douglas Adams                              The Long Dark Tea-Time Of The Soul
+-----------------------------------------------------------------------------+
:   It was signed "You-know-who,"but this had been crossed out and first the  :
: word "Odin" and then in larger letters "Your Father" had been substituted.  :
: Odin never ceased to make absolutely clear his view of his son's            :
: intellectual accomplishments.                                               :
+-----------------------------------------------------------------------------+
 Mark R. Slezak            {tektronix,hp-pcd}!orstcs!nyssa.CS.ORST.EDU!slezakm

------------------------------

Date:    01 Feb 90 07:24:53 +0000
From:    [e-mail] (Dennis Grinberg)
Subject: Re: 4096 and 1260 Viruses (PC)


 [e-mail] writes:
>This is a forward from John McAfee:
.. stuff deleted Topic is 4096 virus
>         We don't yet know the exact mechanisms used by this virus, but
>we do know it works.  No memory resident virus filter, or system virus
>scanner that we are aware of is able to prevent infection from this
>virus, or detect an infection after it has occurred - providing that
>the virus is active.  The only way, currently, that we know how to
>detect this virus is to look for its code in memory.

This is strange because I seem to recall SCAN55 detecting this virus
on a machine that I came across. Is my memory faulty?

------------------------------

Date:    Thu, 01 Feb 90 09:27:00 -0600
From:    <[e-mail]>
Subject: WDEF in Illinois (Mac)

WDEF infections have been reported at Illinois State University.  Our
lab was protected with Gatekeeper Aid and Disinfectant.  Other users
on campus are now using similar tools.Thank you John Norstad!

------------------------------

Date:    Thu, 01 Feb 90 13:51:58 -0500
From:    [e-mail]
Subject: VAX Virus request update (general)

Hi,

     The following was posted to the UMNEWS VAX discussion yesterday
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


Subject:     viruses
From:        Andrew T. Robinson <ROBINSON@BITNIC>

I'd like to stress here that anyone suggesting the distribution of a
virus is opening themselves up for a world of hurt.  I am locking the
user who made the posting about the VAX virus.

***** Received 15:28:37 on 01/31/90, Posting #    86 *****
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

                       Andy Wing
                       Senior Analyst
                       Temple University School of Medicine

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Friday,  2 Feb 1990    Volume 3 : Issue 30

Today's Topics:

Re: Signature Programs
Re: And another WDEF infection (Mac)
Re: Universal virus detector
Re: Internet Worm
Statistical Distribution of Viruses
Re: Universal virus detectors
4096 virus detection (PC)
Jerusalem Disinfectors (PC)
Trojan Alert (MAC)
Help with removing virus requested (PC)
The Ultimate Anti-Viral Solution?
Timestamp virus protection
FSP+ Checksumming

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

---------------------------------------------------------------------------

Date:    31 Jan 90 20:14:06 +0000
From:    well![e-mail] (RSA Data Security)
Subject: Re: Signature Programs


          The following  paper is  presented for review and discussion.  It
          will be submitted to a number of conferences and MD4 will
            be proposed to a number of standards organizations. We encourage
            people to study and evaluate MD4.
          _________________________________________________________________

                          The MD4 Message Digest Algorithm
                          --------------------------------

                                 by Ronald L. Rivest
             MIT Laboratory for Computer Science, Cambridge, Mass. 02139
                                         and
               RSA Data Security, Inc., Redwood City, California 94065


                  (C) Copyright 1989, 1990 RSA Data Security, Inc.

                                          (Version 1/29/90)



          Abstract:
          ---------

          This note  describes the  MD4  message  digest  algorithm.    The
          algorithm takes as input an input message of arbitrary length and
          produces  as   output  a  128-bit  ``fingerprint''  or  ``message
          digest''  of   the  input.   It  is   conjectured  that   it   is
          computationally infeasible  to produce  two messages  having  the
          same message  digest, or  to produce  any message  having a given
          prespecified target  message digest.   The  MD4 algorithm is thus
          ideal for digital signature applications, where a large file must
          be ``compressed'' in a secure manner before being signed with the
          RSA public-key cryptosystem.

          The MD4  algorithm  is  designed  to  be  quite  fast  on  32-bit
          machines.    On  a  SUN  Sparc  station,  it  runs  at  1,100,000
          bytes/second.     On  a  DEC  MicroVax  II,  it  runs  at  70,000
          bytes/second.   In addition,  the MD4  algorithm does not require
          any large  substitution tables;  the algorithm can be coded quite
          compactly.


[Ed. Due to the length of this paper, I've placed it on the
VIRUS-L/comp.virus document archive at cert.sei.cmu.edu, where it is
available for anonymous FTP.  The filename is:
pub/virus-l/docs/md4.rsa.paper.]

          (C) Copyright 1989, 1990 RSA Data Security, Inc.
          All rights reserved.

------------------------------

Date:    Thu, 01 Feb 90 14:01:00 -0500
From:    Peter W. Day <[e-mail]>
Subject: Re: And another WDEF infection (Mac)

The WDEF virus has infected the public computing Labs at Emory
University.

------------------------------

Date:    01 Feb 90 00:00:00 +0000
From:    "David.M..Chess" <[e-mail]>
Subject: Re: Universal virus detector

>        Any time later, I can generate a new list and compare.  It is
> then up to me to decide whether any differences that show up are
> legitimate - but I have the absolute assurance that I WILL get an
> indication of any changes.

Sure, and that's certainly a good first step.  But I still claim that
it isn't by any means a universal virus detector, and would not solve
the virus problem, because the thing that is "up to you" is just too
hard.  The system can tell you that only files that you expect to have
changed have changed, but it *can't* tell you that they've changed
only in innocent ways.  That's one of the largest problems of virus
protection; the system can't in general tell, and certainly can't tell
down below the "which file was changed" level, which modifications to
the executable-set were intended by the user, and which were not.  A
system like this might catch any viruses that we know of today; on the
other hand, if it became widespread, viruses that it would not catch
(or, more accurately, that a human using it would not catch) would
shortly appear.

> Another alternative is to add another bit, the "may create
> executables" bit.  Only code running from a block marked with this bit
> may turn on the "executable" bit for another block.  Normally, only
> the linker and an image copier would have this bit set.  A virus could
> still be written - but it couldn't modify existing code directly, it
> would have to produce object code and pass it through the linker.

Or it could create the object that it wanted, and call the copy
utility.  Or is it impossible for a program to copy a non-executable
thing to an executable thing?  That would help a little, but would
also make the system less convenient to use.  How do you get a new
copy of the linker?  How do you write a patch program?

Don't get me wrong: I think these are all good ideas for future,
more virus-hardened systems.   I just want to point out that,
even if implemented perfectly, they don't make the problem go
away...

DC

------------------------------

Date:    Thu, 01 Feb 90 19:07:04 +0000
From:    grimesg@annapurna (George Grimes)
Subject: Re: Internet Worm

[e-mail] (Geoffrey H. Cooper) writes:
lines deleted ......
>
>One thing that makes me wonder: A newspaper article claims that Morris
>wanted to stop the worm when it started to get out of control, and
>decided that he wasn't able to.  When the Internet group started to
>try and control it, why didn't he offer to help?  At least a copy of
>the source code would have been of great assistance.  Instead, he
>hides and waits for the FBI to find him.
>
>Would not this have been his best opportunity to show his benign
>intentions?  Or perhaps he was advised not to help by someone.

Haven't you ever screwed up badly and then panicked?  Were you
thinking clearly and rationally at the time?  Heavy adrenalin flow is
conducive to flight, not thought.

George

*******************************************************************************
       I speak only for me...let my company form their own opinions!
*******************************************************************************

   +-------------------------------------------------------------------+
   | DOMAIN: [e-mail]        | George Grimes             |
   | INTERNET: [e-mail]         | [phone]             |
   +-------------------------------------------------------------------+

------------------------------

Date:    Thu, 01 Feb 90 16:26:00 -0500
From:    [e-mail]
Subject: Statistical Distribution of Viruses

Greg Gilbert asks:

>Should I purchase the subscription or should I buy each update?  i.e.
>What is the probability in the next year that more than four viruses
>(strains, clones, etc....) will occur?

Well, after all of this clinical discussion, we finally find an
epidemiologist.  (Greg, you will enjoy my paper in "Computers and
Security," Vol. 7 No. 2, April 88.)

The decision is analogous to the decision to be inoculated against a
biological virus.  Such an inoculation has some risk and is not free.
If it is sufficiently effective and if enough others take it, there will
be no one for you to catch the virus from.  This is another way of
saying that the virus no longer finds the population sufficiently
hospitable to prosper and spread.

I have never been innoculated against Polio-myelitis.  I often
experience reactions to innoculations.  I grew up in the midst of
epidemic polio, and was likely immune anyway.  If all of the children,
least likely people to be otherwise immune, took it, a large population
from the most likely vectors would be removed.  Yes, I really did go
through that rational, but mostly I just do not like shots.

We no longer innoculate against Small-pox.

If we could clean up the Universities, Info-Centers, and retail
establishments, we would go a long way toward suppressing viruses.
Indeed, we may have to shut down PC labs.  You can now buy a Toshiba
1000 for $549.00.  This is roughly the equivalent cost of my slide
rule thirty-five years ago.  We did not share slide rules.  The
economic motive behind the shared PCs in a lab has disappeared, but
the unhealthy little cess pools persist.  Clean up your acts!

Best, Bill

------------------------------

Date:    Thu, 01 Feb 90 23:34:52 +0000
From:    [e-mail]
Subject: Re: Universal virus detectors

[e-mail] writes:
> All this debate about whether virus detection is equivalent to the
> halting problem, whether real CPU's are best modeled and FSA's or
> Turing machines, and so on, is interesting but in a deep sense
> completely irrelevant.
>
> With simple hardware support, one can design a system in which all
> viruses are trivial detectable.
>
>         Technique:  The hardware will maintain, in both memory and
>         on disk, an "is executable code flag".  For practicality,
>         assume this is done on a block-by-block basis say in units
>         of a K.
>
>         The hardware enforces the following rules:
>
>         1.  Any attempt to execute code from a memory block which
>         is not marked executable fails.
>
>         2.  The only way to write into a block of memory that is
>         marked executable is from a disk block marked executable.
>
>         3.  Any attempt to write to a disk block marked executable
>         fails.  (To write to such a block, the executable flag must
>         first be cleared.)
>
>         4.  Any disk block can be marked executable at any time.
>
>         Memory blocks are marked executable only by reading execu-
>         table disk blocks into them.
>
>         5.  Associated with every disk block is a time stamp.  When
>         a block is marked executable, the hardware updates its time-
>         stamp.
>
>         6.  The system comes with physical ROM blocks, marked exe-
>         cutable, which contain at least the code needed to display
>         the timestamps on all executable blocks..

...

> Why does this work, despite all the proofs?

The proofs are not relevant to your idea because they deal with the
problem of deciding whether a piece of code is a virus BEFORE it gets
executed whereas your idea is a run-time system. I gather the point is
that only code in executable blocks on the disk can be executed, and
these blocks can never be created or altered in any way, and any
attempt to modify executable memory fails. OK, so your system won't
work unless flexibility is unacceptably reduced.

1. You can't do things like patch the operating system with utility
programs.  I have LOADS of utility programs on both Amiga and MS-DOS
that modify system jump tables etc. I'd far rather have to defend my
system against viruses myself than give up the use of these programs.
So that alone is sufficient to kill your scheme.

2. Sometimes you WANT to modify programs, the main example being use
of a file zap utility to install patches to the executable code of a
program.

3. You're going to HAVE to have a method for at least
creating/deleting executable disk blocks. What if the user wants to
delete or copy a program file? What if you want to extract a program
from an archive? What if you want to compile a program? What if you
want to download a program from a bulletin board? etc. etc... If
applications software can do these things then so can a virus. So your
system isn't going to be very usable, or else you'll have to give up
security. The timestamps are the only thing you're left with and how
many people are going to go into the ROM monitor program to display
the timestamps on every program on their ***-megabyte hard disk to
make sure nothing's been infected? Anyway you could probably work out
some way to beat this given that the virus has access to the video RAM
(which it _has_ to have).

I hate knocking down all these nice ideas. Someone please come up with
something that'll work, I'm beginning to think there isn't any
solution.

"To summarize the summary of the summary: people are a problem"
Russell Wallace, Trinity College, Dublin
[e-mail]

------------------------------

Date:    Thu, 01 Feb 90 14:07:18 -0800
From:    [e-mail]
Subject: 4096 virus detection (PC)

This is a forward from John McAfee:

          A number of people have called about SCAN's ability to detect
the 4096 virus.  When I said we could not detect it on disk, I was
referring to a system where the virus is active in memory.  If the
virus is not already in the system, then SCAN will of course identify
the virus on any file that you wish to scan before you run it.  If the
infected program is executed, however, then SCAN can only detect the
virus in memory thereafter.
          What I'm trying to say, I guess, is that once the virus gets
into memory and gains control, the only detection scheme that seems to
work is a scan of memory.

John McAfee
408 988 3832  (voice)
408 988 4004 (BBS)
408 970 9727 (FAX)

------------------------------

Date:    Thu, 01 Feb 90 14:13:02 -0800
From:    [e-mail]
Subject: Jerusalem Disinfectors (PC)

This is a forward from John McAfee:

          I have seen a few messages recently about the use of M-JRUSLM
for disinfecting the Jerusalem virus.  Please do not use this program,
since we no longer support it.  Clean-Up (CLEANP57) has replaced
M-JRUSLM and all of our other independent disinfectors.  If you have
any of the M-Series disinfectors (M-VIENNA, M-DAV, M-1704, etc.)
please assign them to the bit- bucket and replace them with Clean-Up.
Clean-Up is available on Compuserve, The SIMTEL archives or on
HomeBase at 408 988 4004.  Thank you.  John McAfee

------------------------------

Date:    Thu, 01 Feb 90 15:00:32 -0700
From:    Peter Johnston <[e-mail]>
Subject: Trojan Alert (MAC)

We have detected a new (to us) Macintosh trojan at the University of
Alberta.   Two different strains have been identified.   Both are
dangerous.

The first strain is imbedded in a program called 'Mosaic', type=APPL and
Creator=????.   When launched, it immediately destroys the directories
of all available physically unlocked hard and floppy disks, including
the one it resides on.   The attacked disks are renamed 'Gotcha!'.

Unmounted but available SCSI hard disks are mounted and destroyed by the
trojan.   The files of hard disks are usually recoverable with one of
the available commercial file utility programs, but often the data file
names are lost.   Files on floppy diskettes usually lose their Type and
Creator codes as well, making recovery a non-trivial procedure.

The second strain was detected in a Public Domain program called
'FontFinder', Type=APPL and Creator=BNBW.   It  has a trigger date of 10
Feb 90.   Before that date, the application simply displays a list of
the fonts and point sizes in the System file.

On or after the trigger date, the trojan is invoked and disks are
attacked as for the first strain.   The trojan can be triggered by
setting forward the Mac system clock.

Because the second strain has a latency period during which it is non-
destructive, it is much more likely to be widespread.   Both trojans
were originally downloaded from a local Macintosh BBS here in Edmonton.
The second version was part of a StuffIt! archive named 'FontFinder.sit'
that also contained documentation and the source code for the FontFinder
application.   This source code does NOT contain the source code for the
trojan.

A quick-and-dirty search string for VirusDetective (v/3.0.1 or later)
has been developed that appears to detect the trojan engine in both
strains.   It is:

        Resource CODE & ID = 1 & Data 44656174685472616B

Note that this will detect the currently known versions, but may or may
not detect mutated versions of this trojan.

There is some evidence that these trojans are related based on
preliminary investigation of the code.   It has been speculated that the
second is an 'improved' version of the first (more sophisticated), or
that the two versions were developed by two individual perpetrators
working with the same trojan engine.   There easily could be more
versions either circulating or being developed.

This appears to be the first deliberately destructive malicious code
that targets on the Macintosh.   There is some suspicion that one or
both have been developed locally.   There is also the possibility that
one or both were uploaded from a BBS in the Seattle, Washington area.

Our investigation is far from complete, but is continuing.
Please warn your Mac users to make proper back-ups on a regular basis,
be suspicious of all software not received from a trusted source until
tested, and generally, to practice 'safe computing'.

Any additional information on these two trojans or similar malicious
code would be appreciated.   As and when our investigation turns up more
details, they will be posted...

Peter Johnston, P. Eng.
Senior Analyst, University Computing Systems,
352 - GenSvcBldg, The University of Alberta
Edmonton, Alberta CANADA   T6G 2H1
Phone:  [phone]
FAX:    [phone]
EMAIL:  [e-mail]

------------------------------

Date:    01 Feb 90 10:44:09 +0000
From:    "Arne Gehlhaar" <uniol![e-mail]>
Subject: Help with removing virus requested (PC)

Hello !

This is my first posting (actually my second after a test) and hope
you'll excuse the chaos that I might be just producing ... Anyway I
have the following problem :

I just got an MSDOS exe-file via bitnet from the states, and I was
told that it was infected with the Jerusalem Virus.  Now this happens
to be the first contact I have with any kind of virus.  I *HAVE* been
reading most of the postings to this group, but it didn't make much
sense to me then.

My question is: Do I have to do anything against the virus, i.e. does
it do anything that I might not want ??? If so, what can I do about it
??? Where do I get "anti-virus" programs...preferably without paying
:)

There seem to be quite a lot of you out there who know what's going
on, so could someone please give me some hints ??

Thanks in advance

Arne

PS.: I don't have a signature file... as you can see :)

------------------------------

Date:    Thu, 01 Feb 90 15:37:00 -0500
From:    "Benjamin S. Smith" <[e-mail]>
Subject: The Ultimate Anti-Viral Solution?

An idea which rolled off the top of my head this afternoon:

Every new program which comes out for your computer also has an
"anti-virus module" with it, as a separate data file.  This module
contains information on what actions the program which you have just
acquired takes during operation.  Does the program ever change size?
Does it ever create additional files?  Is it authorized to make
changes to other programs?  What kinds of changes?  How is it allowed
to make such changes?  Does it ever run/read other programs or data
files?  and so on.  Included would be a list of all required
read/write actions which the program uses.

A central program, included with your computer from its manufacturer,
is in charge of overseeing every one of these data files.  It is a
system-wide guard against unauthorized attempts from within any
program to modify data on your computer.  If a problem occurs, the
central program spells it out for you and asks for further
instructions.

Somehow the central program would have to be referenced with every
read and write, admittedly a long process.  Maybe the program could be
a piece of hardware, a chip, or extra memory simply set aside to be
used only by the central program.  Also, the more programs you have,
the more that the central program must keep track of.  Perhaps too
much information to deal with at once.  But it sounds good, right?

This way the burden for virus protection falls on the computer
manufacturer and the software companies themselves.  No new updates of
anti-virus programs are needed, since the computer can recognize any
"incorrect" activity.  Saves your $$, as you don't have to subscribe
to an anti-virus updating service.

Feasible?  Or just too complicated?  Could such a setup be compromised
in any way short of hardware failure?  Give it some thought.....

Ben Smith
[e-mail]

------------------------------

Date:    Thu, 01 Feb 90 00:00:00 +0000
From:    "Prof Arthur I. Larky" <[e-mail]>
Subject: Timestamp virus protection

Perhaps I'm Missing Something

>Date:    Wed, 31 Jan 90 13:13:00 -0500
>From:    [e-mail]
>Subject: Re: Universal virus detector

>While it may sometimes be difficult to decide exactly what catagory
>some transitions fall into, in many cases I can be definitive.  In
>particular, there it is almost always the case that no existing
>executable should be modified, ever.  All my existing executables can
>be checked by comparing their timestamps with known-correct values.
>Think of this as a very cheap, absolutely unforgeable checksum.

>More generally, any time I am certain my system is "clean" I can
>generate and save on a secure medium a list of all timestamps on my
>disk.  Any time later, I can generate a new list and compare.  It is
>then up to me to decide whether any differences that show up are
>legitimate - but I have the absolute assurance that I WILL get an
>indication of any changes.

  I hope we're not talking about the timestamp that MSDOS puts on
a file.  Any time you want to change one, MSDOS will be glad to do
so for you since that's what Int 21H function 57H does for a living.
If you don't want to write in assembly code, it's only a few lines
in Turbo Pascal.

>For example, you can add a
>hardware-enforced switch which when in the OFF position makes it
>impossible to set the "is executable" bit at all.  In this mode, you
>can't do program development, install new executables, or even copy
>executable files - but you absolutely can't be infected either.  The
>vast majority of systems could probably spend most of their time with
>the switch in this position.

But that's what I do for a living: "program development, install new
executables, etc."  Oh, well, one can always retire to something less
challenging such as urban warfare.

>Another alternative is to add another bit, the "may create
>executables" bit.  Only code running from a block marked with this bit
>may turn on the "executable" bit for another block.  Normally, only
>the linker and an image copier would have this bit set.  A virus could
>still be written - but it couldn't modify existing code directly, it
>would have to produce object code and pass it through the linker.

  I translate this to mean "find something other than a PC or a MAC
on which to do your computing."  True, but it doesn't solve the current
problem for most of us.

Art Larky
Professor of Electrical & Computer Engineering
Lehigh University
215 Packard Bldg 19
Bethlehem, PA 18015

For all I know, this may not even be my opinion, let alone Lehigh's.

------------------------------

Date:    Fri, 02 Feb 00 19:90:53 +0000
From:    [e-mail] (Ross M. Greenberg)
Subject: FSP+ Checksumming

Y. Radai <[e-mail]> writes about the checksum *installation*
being too difficult for many people to use, and that, therefore, the
presumption I make that "nobody has complained" (basically) might not
be representative of the actual situation out there.

Well.  He could be right.  I must admit that, if I were writing the
program all over again, the installtion procedure would have been made
a lot easier.  In my wildest dreams, I never expected the program to
have the success it has.  However, in shareware, there always must be
an incentive for people to register the program - else I don't make as
much money as I could.  Registered users of FLU_SHOT+ get an
installation program that makes the job a little easier - still not as
easy as falling off a log, but a little easier.

Users of my commercial program get something that is as easy as
falling off a log, though, and get a choice of different checksum
routines.  They can even pick more than one routine, and combine the
resulting checksums/sigs into one signature.  If people are expecting
some real sophisticated checksumming stuff, though, they won;t find it
in my stuff for the reasons I've outlined before.  Perhaps I'll
include some real tough checksumming in the commercial product, if
there is enough interest.  So, far, there doesn't appear to be any
real interest, except (potentially) by *some* of the readers of this
mailing list.

>Sorry, but I don't understand why you have to get back to the "real"
>checksum.  Suppose we improve the security by making the checksums
>different for each user.  From the fact that some user's checksum has
>changed relative to *whatever* it was when that user set up his
>checksum base, we'd know precisely the same thing that you know by
>comparing with the "real" checksum, namely that his file had been
>altered (which *may* indicate infection).  So what do you gain by use
>of the "real" checksum?

I get people calling me up with problems on them checksumming already
infected files.  In most of these cases, they were not aware of the
problem.  By knowing the checksums of some popular programs (not just
the system files), I can ask them to forward me a list of their
checksummed files, ask a simple question or two and then figure out,
potentially, what file is infected.

Remember that I'm supporting (as of date) just over 20K users.  That
causes me to have to make some compromises, and more's the pity: each
update has to take longer because it affects more people, more users.
There are estimates that only 1% of the users of shareware ever
register.  If this is the case, then I have a responsibility to take
things *very* slowly with any change I make.

That's not to say that I won't consider making such a change, just
that there is a heckuva lot more that goes into making a change that
increases the security of the product by .00001% (or whatever) but
that affects 100% of the users, registered or unregistered.  I have a
wish list of changes to make to the shareware version and to the
commercial version.  For obvious economic reasons, the commercial
version gets all the enhancements first.  For certain legal reasons,
some changes can never make it into the shareware version.

Just to reiterate: I never expected FLU_SHOT+ to have the popularity
that it does, nor did I realize the restrictions such popularity
places on the author when it comes to updating the code.

Ross

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Monday,  5 Feb 1990    Volume 3 : Issue 31

Today's Topics:

Included privileges with programs
Re: Virus Modeling
Help with Using Clean! (PC)
WDEF-A report (Mac)
Re: The Ultimate Anti-Viral Solution?
Virus detection through change detection / authorization
RE:YANKEE DOODLE (PC)
Viral Help (PC)
F-PROT and Virus Buster (PC)
WDEF on campus (Mac)
Re: 4096 and 1260 Viruses (PC)
Re: Universal virus detector
Re: Statistical Distribution of Viruses
WDEF A at the USC (Mac)
AIDS Trojan - the Police charge a US Citizen
Re: Gatekeeper veto: Normal behavior or virus attack? (Mac)
Universal virus detectors: Once more with feeling
AIDS Virus Suspect Arrested Near Cleveland, Ohio
Washington Post story on Joseph Popp; FYI

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

---------------------------------------------------------------------------

Date:    Fri, 02 Feb 90 09:56:13 -0500
From:    [e-mail]
Subject: Included privileges with programs

Hi,

     Ben Smith had an idea to monitor actions taken by programs
and compare those actions with what the vendor says the program needs
to do in order to function.

     I hate to shoot this down but consider this hypothetical case:

"PC-DOS V8.0" includes a security monitor with a list of privileges
for "Norton Super Utilities V6".  This list has "modify memory" and
"write boot sector" listed for Norton.

     Now suppose that a virus instead of trying to modify the boot
sector by itself, modifies Norton Disk Doctor to do the dirty work?
The monitor program would allow the Disk Doctor full access to the
boot sector and not know that it was really a corrupted Disk Doctor
actually writing viral code to the boot sector instead of making
repairs like the Disk Doctor normally does.

     My point is that even if a program is allowed to perform some
action, how is the monitor supposed to know whether that action is
legitimate or not?


                       Andy Wing
                       Senior Analyst
                       Temple University School of Medicine

------------------------------

Date:    02 Feb 90 15:46:01 +0000
From:    [e-mail] (Greg Fife)
Subject: Re: Virus Modeling

[e-mail] writes:
>                                        As someone pointed out, a real
>computer isn't a finite state machine because it includes the person
>operating it

A human being may or may not be a finite state machine, but the
effect he he has on a computer system is merely to add a finite
number of transitions to the computer. (Striking one of the finite
number of keys changes the interrupt state on a PC, putting in
a new disk changes many of the bits on that mass storage device).

You can't model exactly which inputs the human will provide, but
you can reason about behavior under any possible set of inputs.
In effect, a person at a computer is running a huge finite
automata through an input string consisting of his actions.

Take the initial state to be one of the finite number of
states which represents the introduction of the virus into
the system.  Mark the finite number of states which represent
"infection" as final states.  The question: "can infection occur"
is merely the question "does this FA have a nonempty language."
That question can be settled in finite time by testing the FA
on every input string of length less than or equal to the number
of states in the FA.  Do this once for every initial "infection"
state, and the result follows. :-)

You may need to add a few more states to better model
the input devices and the clock.

>(well the whole universe has a finite number of states
>but we're getting way beyond anything of practical use).

Yep.

                            Greg Fife
                            [e-mail] , virginia.bitnet
                            uunet!virginia!uvacs!gnf3e

------------------------------

Date:    Fri, 02 Feb 90 12:41:00 -0400
From:    Michael Greve <[e-mail]>
Subject: Help with Using Clean! (PC)

    I tried using M-Jruslm on a .exe file.  After it was finally done
disinfecting the file it would no longer work.  When trying to run the
.exe file my machine froze.  I have downloaded CLEANP57 and tried
running it but have been unsucessful.  I'm following the directions
that come with the program but I'm still having problems.  I'm typing
the following:

                 CLEAN A:\FILE.EXE [JERUSALEM B]

When I try it this way I get "Sorry I don't know anything about
[Jerusalem B].

When I try:

                CLEAN A:\FILE.EXE JERUSALEM B

it comes back with the instructions again.  Nothing happens.  I know
I'm not using this correctly.  Can anybody help with the proper
syntax.  When it asks for the "virus name", what do I type in for
Jerusalem B.  Do I use the [] brackets.  Do I have the correct
version.  I am running CLEAN 2.7V57.  When I run it, I do get a
message saying "This program may not be used in a business,
corporation, organization, government or agency environment without a
negotiated site license."  I'm not sure if this is the problem or not.
If I have a bad version, where could I get the correct one.  I've
tried getting onto Simtel but either cannot its very busy or I end up
downloading unusable or corrupted files.  I got this from the
"130.160.20.80" list.  Does anybody know of others I can use??  I'm
new to all this so please bear with me.  Thanks for any assistance.  I
really want to get rid of this virus.

                                        Michael Greve
                                        University of Pa.
                                        Wharton Computing
                                        [e-mail]

------------------------------

Date:    Fri, 02 Feb 90 10:11:00 -0500
From:    "Anne Harwell/Technology Resources Ops. Mgr." <[e-mail]>
Subject: WDEF-A report (Mac)

For those of you keeping track, WDEF-A has arrived in south Texas at
University of Tecas - Pan American. I had not heard of it getting this
far south until yesterday, when a routine virus inspection of the Mac
lab revelaed WDEF-A. The infection has been disinfected and I am sure
that it will recur next week, because many of the students in the lab
had infected floppies.

Anne Harwell
Technology Resources
University of Texas Pan American
AH491D@PANAM

------------------------------

Date:    02 Feb 90 19:13:16 +0000
From:    [e-mail] (David Vronay)
Subject: Re: The Ultimate Anti-Viral Solution?

Well, the idea of programs containing descriptions of their own
activity is nice, but doesn't really solve the problem.  After
all, all an infecting virus has to do is change these permission
files.  Or better yet, the virus could patch the code that did
these checks so that the code would let this particular virus
go through.  If we think about how current virus detection programs
"work", they basically do exactly what you described (only, instead
of each manufacturing describing the program's behaviour, the burden
is on the user).  Take SAM, for instance, which can keep track of
legal and illegal activities on an application-by-application basis.
When it detects illegal activity, it brings up a dialog box that says
"Allow"  "Deny" and "Learn" (or three similar options).  Clicking on
"Learn" will change SAM's description of that program to allow that
potentially-illegal action in the future.  Now, that information is
stored in SAM somewhere, where any moderately clever virus could
find it and modify it.  Now, let's go one one step further and pretend
that Symantech made it impossible (via some yet-undiscovered hardware
scheme) for SAM to be modified.  Now our virus would be forced to
use the following piece of pseudo-code:

Step 1:  Set the window-manager's port 16,000 pixels to the left
Step 2:  Set up dialog-box sniffer code that works at _vblank time.
Step 3:  Do illegal virus activity
Step 4:  SAM brings up its dialog box, which now appears about 16
         feet off the screen due to step 1.
Step 5:  The dialog sniffer from step 2 "sees" the dialog and
         generates a mouse-down event over the "Learn" button.
Step 6:  SAM writes the new exception to its special harware
Step 7:  Restore the window-manager's port to its old position.

We have now successfully infected, despite all of super-SAM's
harware whatever.

Let's face it.  There is NO WAY WHATSOEVER to make a computer
virus-proof, because there is no way that a computer can
determine the true intentions of a piece of code.  (which, in tern,
is due to the fact that code doesn't HAVE intentions, only the
programmer who wrote it has intentions, and guess what?  They
don't make it through the compile! :-)

We should concentrate our efforts on education, not complex software
solutions.  After all, computer virii seem more a social problem
than a technological one.

- - ice
==================
email replies to: [e-mail]
DISCLAIMER:  Not even I subscribe to everything I say
==================

------------------------------

Date:    Fri, 02 Feb 90 14:07:03 -0500
From:    "David W. Levine" <[e-mail]>
Subject: Virus detection through change detection / authorization

When we try to evaluate schemes for detecting and preventing
the spread of viruses, it's important to remember that a virus
uses those operations a user normally does to spread. If a
virus only infects programs when you do something to modify
an executable program, you now have to determine that the
modification that was made was the one you desired. That's
a correctness problem, which we know is undecidable.

Determining what's executable, on modern day systems, is
also a very hard problem. Any systems that have shell
languages, or interpreters complicate this task immeasurably.
What does a shell script look like? A text file. What does
a hyper-text stack look like? While the current generation
of micro-computer viruses live mostly in program images,
there is no requirement that this be true in the future.

We can slow down the spread of viruses through lots of
different mechanisms, but each of these mechanisms reduces
the utility of computers. As long as we want our computers
to be general purpose machines, with lots of flexibility,
the virus writers will be able to exploit a programs legitimate
capabilities to spread viruses. Distinguishing between normal,
legitimate, change and illicit change is a very difficult problem.

                           - David W. Levine

------------------------------

Date:    Fri, 02 Feb 90 17:07:19 +0000
From:    [e-mail]
Subject: RE:YANKEE DOODLE (PC)

Hi,
A few weeks ago, I asked about info and disinfector for the Yankee doodle
virus on a PC. It seems nobody knows anything about it, since I haven't
got any answer, so anybody out there has any idea !!
Last week, I downloaded "CLEAN UP" from Simtel, which claims to cure many
strains including Yankee Doodle, But the only thing it manages to do is
to offer deleting the infected file. I don't want to be rude, but what's
wrong with the good old DOS ">DEL file.ext" ?. Why to bother writing code
to do what DOS can do.

O. FADEL

- ------------------------------------------------------------------------------
Research student         | JANET   :  [e-mail]
Computer Science Dept.   | ARPANET :  [e-mail]
Bristol University       | BITNET  :  [e-mail]
BRISTOL, UK              | UUCP    :  ... !mcvax!ukc!csisles!ousama
BS8 1TR                  |
- ------------------------------------------------------------------------------

------------------------------

Date:    02 Feb 90 20:02:02 +0000
From:    James Kolasa <[e-mail]>
Subject: Viral Help (PC)

I've been having some problems with some PC's at the college where I teach.
The evidence points to a virus.  Someone from IBM ran a virus scanner on
a couple PC's and got the following message:

Found signature in (master boot record of drive 80) at offset 21 (15H):
1E5080FC02721780FC047312AD2750E33C08ED8A03F04A8017503E80700
A boot record of this disk may be infected with the Stoned virus.

Does "Stoned virus" ring a bell with anyone.  Could someone give me some
backgroud info?  References to past messages will be appreciated also.

                                    Thanx,
                                     jk

- --
- --   James Kolasa                |      "Computers are so naughty,
 --
- --   121 Moloney, L.C.C.         |          I could just pinch them"
 --
- --   Lexington, Ky.  40506-0235  |                   -The Martian
 --
- --   [e-mail]   {rutgers,uunet}!ukma!jkolasa   [e-mail]
 --

------------------------------

Date:    Fri, 02 Feb 90 17:15:10 +0000
From:    [e-mail]
Subject: F-PROT and Virus Buster (PC)

Hi,

I tried to use VB_110.ARC to disinfect some files infected with Vienna
Virus, it works on some and leaves few without even sensing that the
virus is still exist, anybody has the same experience??

Another point, Running F-FCHK.EXE on a disk containing VB.EXE it gives
the message:    VB.EXE  suspected virus Alabama. While SCAN does not
detect anything wrong, any suggestion ??

O. FADEL

- ------------------------------------------------------------------------------
Research student         | JANET   :  [e-mail]
Computer Science Dept.   | ARPANET :  [e-mail]
Bristol University       | BITNET  :  [e-mail]
BRISTOL, UK              | UUCP    :  ... !mcvax!ukc!csisles!ousama
BS8 1TR                  |
- ------------------------------------------------------------------------------

------------------------------

Date:    Fri, 02 Feb 90 15:38:00 -0600
From:    [e-mail]
Subject: WDEF on campus (Mac)

FYI

The WDEF virus has reached us here at Texas Christian University. A
student came into our User Services area to obtain virus software and
one of his disks was infected. Luckily I had installed GateKeeper Aid
the day it came out. I just wanted the list to know how far this thing
has spread.

Karen Moncrief
Sr User Services Consultant
Texas Christian University
Fort Worth, Texas 76129
AppleLink:      U1069
Bitnet:         MONCRIEF@TCUAVMS

------------------------------

Date:    Fri, 02 Feb 90 23:19:13 +0000
From:    [e-mail] (David Dyer-Bennet)
Subject: Re: 4096 and 1260 Viruses (PC)

John McAfee writes:
:       The strangest part of the virus is that it is also able to
:trap all other disk reads and writes, and whenever an infected file is
:accessed by any program, the virus performs a disinfection of the
:program on the fly.
 ^^^^^^^ infected file?

As a BBS sysop, I find this a particularly amusing feature: it assures
my users that anything downloaded from my BBS is not infected with
this class of virus!  The concept of BBS's as *the safest* source of
software (at least in this one regard) is rather amusing.

- --
David Dyer-Bennet, [e-mail]
or [e-mail]
or Fidonet 1:282/341.0, [phone] 9600hst/2400/1200/300
or terrabit![e-mail], ...{amdahl,hpda}!bungia!viper!terrabit!ddb

------------------------------

Date:    Fri, 02 Feb 90 16:53:56 +0000
From:    [e-mail] (Peter da Silva)
Subject: Re: Universal virus detector

> For example, you can add a
> hardware-enforced switch which when in the OFF position makes it
> impossible to set the "is executable" bit at all.

So far so good.

> In this mode, you
> can't do program development, install new executables, or even copy
> executable files -

Pretty much so.

> but you absolutely can't be infected either.

Not true. What constitutes an "executable file"? Is a BASIC program one?
You can write a virus in BASIC. How about Postscript? You can hide a
virus in Postscript. You can't turn off your BASIC or Postscript
interpreters...

This is the basic sort of protection used by old Burroughs computers: only
the compilers could create executable files, and they were trusted programs.
They had no memory protection hardware at all.
- --
 _--_|\  Peter da Silva. [phone]. <[e-mail]>.
/      \
\_.--._/ Xenix Support -- it's not just a job, it's an adventure!
      v  "Have you hugged your wolf today?" `-_-'


------------------------------

Date:    Fri, 02 Feb 90 22:14:19 +0000
From:    [e-mail] (Peter da Silva)
Subject: Re: Statistical Distribution of Viruses

[e-mail] writes:
> I have never been innoculated against Polio-myelitis.

> We no longer innoculate against Small-pox.

The two cases are not equivalent. Smallpox doesn't have a non-human
vector.  Polio does... in fact I believe that stagnant water can serve
as a reservior for Polio. So we can't "eradicate" Polio the way we
have (almost) Smallpox.

Now I'll leave it up to you folks to decide which of these should
serve as a paradigm for Viruses.
- --
 _--_|\  Peter da Silva. [phone]. <[e-mail]>.
/      \
\_.--._/ Xenix Support -- it's not just a job, it's an adventure!
      v  "Have you hugged your wolf today?" `-_-'

------------------------------

Date:    Fri, 02 Feb 90 23:08:54 -0500
From:    "Gregory E. Gilbert" <[e-mail]>
Subject: WDEF A at the USC (Mac)

Guess that says it all.

So far we have seen two (2) infected disks at the computer center Mac
lab.  However, there are numerous other Mac labs that are not as
concerned about viruses as we are.  I assume we will see more infected
disks.

                                                Greg.

Postal address: Gregory E. Gilbert
                Computer Services Division
                University of South Carolina
                Columbia, South Carolina   USA   29208
                [phone]
Acknowledge-To: <C0195@UNIVSCVM>

------------------------------

Date:    Fri, 02 Feb 90 07:53:00 -0700
From:    [e-mail] (Alan Jay)
Subject: AIDS Trojan - the Police charge a US Citizen

Yesterday afternoon in Clevland Ohio the FBI arrested a man on
blackmail charges relating to the AIDS trojan program sent out from
the UK in December.

The suspect, Dr Popp aged 39, was arrested at his parents residence.
He will appear in court today on the blackmail charge and extradition
procedures are under way.

=========================================================================

I wonder if anybody out there knows anything more about the gentelman
concerned with this event.  If so please email me and I will summarise.

Alan Jay

PS I think it is interesting that unlike the recent 'internet' case
that the charge is blackmail.  I suspect that this is due to the
current state of UK law.

- --
Alan Jay - Editor Connectivity              The IBM PC User Group, PO Box 360,
Tel.     [phone]   Fax: [phone]     Harrow HA1 4LQ, ENGLAND
Email:   [e-mail]                Path: ..!ukc!ibmpcug!alanj
***  For all users of IBM PC & ALL Compatibles  *** (+ Standard Disclaimer)

------------------------------

Date:    Sat, 03 Feb 90 15:17:36 -0600
From:    [e-mail] (Alexis Rosen)
Subject: Re: Gatekeeper veto: Normal behavior or virus attack? (Mac)

[e-mail] (Norman Swenson) writes:
>I have noticed something suspiciously virus-like on my Mac II.  I was

        First the good news.
        This is almost certainly not a virus.
        To make sure, find out if the file signature of ADoBe Separator
        is ADBS. If it is, you're fine.
        Otherwise, you might have a problem.

>getting a "Serious disk error" message from Microsoft Word and garbage
>in my files when using the editor in TeXtures.  Fearing an imminent
>disk crash, I backed up my hard disk to another.  While the files were
>copying over. I got a veto message from Gatekeeper (ver 1.1.1, w
>Gatekeeper Aid).  I decided to check my disk using Disinfectant 1.5...

> ...However, whenever I try to open the Illustrator folder on the backup
>disk, I get the following veto message: 'Gatekeeper has vetoed an
>attempt by Finder to violate "Res(other)" privileges against Desktop.
>[AddResource(ADBS,0)]'.  I have isolated the behavior to the Adobe
>Separator 2.0 program.  When I remove it from that folder, I do not
>get the message.  When I put it back, I don't get the message the
>first time I open the folder, but I do every time after that.  I made
>a copy of the folder on another disk, and at first I got the same
>behavior, but after I rebooted it went away on the second disk.  I
>looked at both desktop files using resedit; one had the ADBS resource
>in it, the other did not.  Is this normal behavior, or could it be due
>to a virus that Disinfectant 1.5 is not catching?  Why would opening a
>folder require adding a resource to the desktop file?  And why did
>Gatekeeper veto it on one disk, but not the other?

    I've seen this coming ever since the GK-Aid INIT was released- but
    then again, I anticipated WDEF in a message about seven months ago,
    and all of this revolves around one concept- file signatures that look
    like code, and vice versa (I can't claim any great genius on this,
    though- I got the idea from seeing C. Weber's FKEY Manager program
    cause crashes on Cmd-Shift-0... anyone else remember that?).

    To answer your questions (as best as I can from your description), the
    Adobe Separator utility has a file signature which happens to have the
    exact same four bytes as a type of executable resource that lives in
    the system file.  Now while I've never seen the GateKeeper-Aid, I'm
    pretty certain I know exactly what it does- it prevents any resource
    which looks like executable code to the Mac OS from going into the Mac
    desktop. This is a well-defined list which includes (not surprisingly)
    WDEF.

    So what happened was, when Separator was put on your hard disk, you
    didn't have GK-Aid, and so the Separator bundle (signature ADBS) was
    added to your desktop (as it should have been). When you tried to open
    the folder containing Separator for the first time, on your other
    disk, you were running GK-Aid.  At that point, the Finder wanted to
    add the bundle resource 'ADBS' to the second disk's Desktop file, and
    GateKeeper vetoed it.

    In summary, everything is OK (as long as I'm right that Separator's
    signature is 'ADBS'). GK and the Finder are both behaving as they
    should. The folks at Adobe get the programming-fools-of-the-week award
    for picking such a bad signature. Nothing to shoot them over, though.

    If you just override GK long enough for the signature to get into the
    desktop file, it will stop bothering you (the Finder only adds a
    bundle once).

Hope this helps (and I _really_ hope it's right)--
Alexis Rosen
[e-mail]
{apple,cmcl2}!panix!alexis

DISCLAIMER: IF A NEW VIRUS TRASHES YOUR DISK, DON'T BLAME ME.

------------------------------

Date:    Sat, 03 Feb 90 18:17:00 -0500
From:    [e-mail]
Subject: Universal virus detectors: Once more with feeling

David Chess continues, in essense, to complain about the user
interface.  He says that determining which changes to executables were
deliberate and which not is too hard, etc.  This again misses my
point.  I was not trying to sell anyone on a "solution to the virus
problem".  I was trying to point out that the apparent THEORETICAL
impediments to virus DETECTION were in no sense basic, but were
side-effects of the particular ways we have chosen to build our
hardware and our mathematical models.  We can make other choices if we
wish.

He also asks:

        Or it could create the object that it wanted, and call the copy
        utility.  Or is it impossible for a program to copy a non-executable
        thing to an executable thing?  That would help a little, but would
        also make the system less convenient to use.  How do you get a new
        copy of the linker?  How do you write a patch program?

No, on such a system you could not copy a non-executable thing to an
executable, unless you chose to have a copy routine which was marked
"may set the 'executable' bit".  Most people do not need patch
programs - most people are not programmers.  Those who need a patch
program can give it the appropriate rights.  You create a new linker
by linking one with the old one, if you are in the business of
creating new linkers.  Or you install one, already marked as
executable, from a binary disk you got from a trusted source.

Russell Wallace has two complaints: That this technique only catches
viruses at run-time, rather than by examining the code, and that
various things he does on his Amiga, like patching code, would become
impossible.  For the first, I suggest that *I* examine code by running
it on my CPU - it's much better at looking closely at things than I
am.  Today, that's a dangerous thing to do, since the act of
examination may let a virus do damage.  On a properly built system, I
would be told if the code tried to do anything to any of my
executables.

As for patching and such: The machines I described are perfectly
capable of doing anything any current machine can do.  If you give a
patch program the right to create executable code, it will work just
as it does today.  Of course, in the process you give up some of your
protection.  Hey, if you release the safety on a gun, you could
accidentally shoot yourself.  Imagine that!

Arthur Larky writes: "Perhaps I'm Missing Something" and points out
that an MS/DOS timestamp is worthless.  Yes, he did miss something -
my article which talked about where these timestamps come from.
Sorry, not from MS/DOS or any existing software or hardware....

He also says:

        But that's what I do for a living: "program development, install new
        executables, etc."  Oh, well, one can always retire to something less
        challenging such as urban warfare.

Welcome to the real world.  Only a minority of us do program
development, a minority that is growing smaller every day.  While most
owners of PC's have to install executables, that involves a minute
fraction of the time they spend using their systems.  If a system
protected them, it would be well worth building.  As to the developers
- - they are inherently doing something riskier, and will have to watch
their systems more carefully.  With the "no new executables" switch
off, they can develop - and be infected - as always.  They still get
the hardware modification log if they want it.

        I translate this to mean "find something other than a PC or a MAC on
        which to do your computing."  True, but it doesn't solve the current
        problem for most of us.

You bet.  But, to repeat myself, I wasn't TRYING to solve anyone's
current problems - I was trying to show that a solution is POSSIBLE,
if we decide it is worth the costs.  The problems involved are
monetary/political/organizational, NOT technical.
                                                        -- Jerry

------------------------------

Date:    03 Feb 90 17:57:50 +0000
From:    nitrex![e-mail] ( Dr. Robin Lake )
Subject: AIDS Virus Suspect Arrested Near Cleveland, Ohio

                         COMPUTER BLACKMAIL ALLEGED
                  Lake [County] man held on British counts

For  those of you  who don't find  the Cleveland Plain  Dealer on your
doorstep or bushes each morning ----

>From Page 1 of The Plain Dealer, Cleveland, OH, Saturday, February 3
By META McMILLAN, Staff Writer

"  A Willowick man  is being held without  bond on a federal  fugitive
warrant, pending   extradition  to England  to  face    blackmail  and
extortion  charges in connection with a   computer disk that scrambled
and stymied computer systems across Europe and Africa.

Joseph L.  Popp Jr., 39, of W.  Willowick Dr., was brought before U.S.
Magistrate Joseph    W.  Bartunek  yesterday morning,   complaining of
mental illness, to face charges that the disk he allegedly created and
mailed to  as many as 26,000 businesses  and hospitals  was part of an
elaborate blackmail scheme.

Authorities in England  are seeking to extradite  Popp under the terms
of a 1972 treaty with the United States.

Bartunek delayed the extradition hearing until after he can review two
psychiatric  evaluations  of   Popp.    The magistrate   ordered   the
examinations  --- one by a  court-appointed psychiatrist and the other
by Popp's doctor --- after Popp's lawyer told the judge his client was
suffering from mental illness and was on medication.

Bartunek  said he expected the  psychiatric  reports   to be available
within  10 days, after  which he will determine  whether  a competency
hearing is needed before an extradition hearing is scheduled.

Popp  was arrested   Thursday  without  incident  by FBI   agents  and
Willowick police at the home he shared with is parents.  A warrant for
his arrest was issued Jan.  18 by a London  magistrate.  A sealed U.S.
warrant was issued Jan.  24 by U.S. District Judge Ann Aldrich.

Scotland Yard charges that about Dec. 11, while he was in London, Popp
mailed  20,000  to  26,000  IBM  data  disks to  hospitals,  insurance
companies and major corporations.

The disks purportedly  provided information on  what individuals could
do  to reduce their  chances  of  catching acquired immune  deficiency
syndrome.

After some   computers became infected  by  the  program,  word of the
potentially destructive disks spread within days, and  AIDS researches
in the United States were put on alert.

Companies  in African nations,  England, Belgium, Denmark, Holland and
Australia received the  disks, London  officials said.   Investigators
believe no disks were mailed to the United States or Canada.

The packages containing the  disks bore a  printed warning  that users
would be billed up to $378 for use of  the disk.  Payments  were to be
sent to PC Cyborg Corp., whose address is a post office box in Panama.

Gary Arbeznik,  an     assistant  U.S.  attorney,  said  that   London
authorities had told  U.S. investigators that "when  the disk was used
in a  computer, an  AIDS  program was generated.  At   the end of that
program, the screen would go blank, except for  an invoice, which said
"if you wish to  use this computer,"  up to  $378  must be paid  to an
address in Panama.

"When the money was  paid, an antidote  would be sent," Arbeznik said,
"Until then, the machine was unusable."

Popp is believed to have used the mailing list from PC Business World,
a London computer publication, to target recipients of the disks.

Officials of PC  BUsiness World  said  a  man  identifying  himself as
"Ketema," an African businessman, contacted the magazine's circulation
department in October about purchasing part of  its mailing  list.  He
paid more than $1,000 for 7,000 names, the magazine said.  About 1,200
of those  PC  users were hit with  the virus; the  rest were warned in
time, said senior reporter Mark Hamilton.

PC Business World said Cyborg also used other mailing lists.

Cyborg's directors are listed  as  Kitain  Mekonen, Asrat Wakjira  and
Fantu Mekease.

The suit for  extradition  said  Popp  began planning the   scheme  in
February 1989, when he set up the Panama firm.  FBI spokesman Bob Hawk
said the bureau had information that Popp was  prepared to mail out an
additional 2 million disks.

Popp, soft-spoken with dark hair and flecks of gray in his dark beard,
was  handcuffed as he appeared  in  the  courtroom.  He was dressed in
loafers, faded blue jeans and  a multicolored   sweater.  His eyes  at
time darted anxiously toward the few spectators in the courtroom.

He was  rushed in  and out  of   the federal courtroom    through back
entrances.

Popp   is a  zoologist and  anthropologist  who has conducted   animal
behavior research for several international health agencies, including
UNICEF   and  the World Health  ORganization.   He  said  he was under
psychiatric  care and taking medication  for a  mental illness.  Twice
during  the  morning  hearing,   he  said   he was  not  clear   about
proceedings.

Bartunek ordered the courtroom cleared  so Popp could consult with his
lawyer, John Kilroy,  who practices  in Euclid   [Ohio].  The  meeting
lasted  several minutes, after  which Bartunek again apprised Popp  of
the charges.

Popp  said he  understood  what  they  involved   but added  "I do not
understand how  it applies to  my  case."  Kilroy unsuccessfully asked
that Popp be held in a psychiatric hospital rather than in jail.

Kilroy described Popp,   and  Ohio  State  University graduate  [1972,
biological science]  with a  doctorate  in anthropology from   Harvard
University  [1979],  as  a  respected  anthropologist  being  unfairly
painted as a criminal.

Popp  left  the World Health Organization,  a  special agency  of  the
United  Nations,  a  few weeks before  Christmas  and returned  to his
parents' home, Kilroy said.

Popp received no money  in his  endeavor to  market the   flawed disk,
Kilroy said, but  had hoped  to generate money  to conduct research on
the AIDS virus.

Kilroy  said  he did  not have  enough information  to explain why the
disks apparently had shut down computer  systems across two continents
and in some cases destroyed the information those systems contained.

He   said he had  had only  two brief  interviews with Popp  since his
arrest.

John Austen, an investigator with  the computer crimes division of New
Scotland Yard, said  Popp's actions were  motivated  by money and that
Popp could face up to 10 years in prison for  each count of blackmail.
He declined comment on whether investigators believe Popp acted alone,
but  a    recent article in  the  Times   of London referred     to an
investigation seeking four men in connection with the virus.

Popp was moved  after the hearing to  an undisclosed jail.    Bartunek
told Kilroy to  make a  list of medications  Popp  required so federal
marshals could  ensure that he  received them.  Popp has complained to
Bartunek  that  while  he was held at the  Lake  County Jail after his
arrest Thursday, he as not given proper medication.

"I am deeply disturbed at  times,"  he told Bartunek, "and  one day in
custody  ... can be  a day of disorientation."  "   Staff writers Eric
Stringfellow and Rebecca Yerak contributed to this article.  "

[Sidebar articles include  a diagram  of  a PC  with  a Computer Virus
Glossary:  "Time   bomb,  Logic bomb,  Trojan    horse,  Vaccine"; and
"Neighbors express surprise at arrest".  Summary: "Quiet, Intelligent,
Outstanding young   man.  He  was  a  real smart  kid  ...  we  didn't
socialize that much, but I always figured he would end up being a CPA.
I remember him as a real gentleman.]

------------------------------

Date:    Sun, 04 Feb 90 09:39:00 -0500
From:    <[e-mail]>
Subject: Washington Post story on Joseph Popp; FYI

From:  The Washington Post, February 4, 1990. Page 18.
Byline Reuter.

  "Cleveland, [Ohio] Feb. 3 -- An anthropologist accused of
international computer fraud involving information about AIDS and a
possible computer virus was held without bail while a judge considered
reports on his sanity, authorities said today."
  "Joseph Popp, 39, appeared before a U. S. magistrate to face charges
that the computer disk he created was part of an international
blackmail scheme, said Assistant U.S. Attorney Gary Arbeznik."
  "The Cleveland Plain Dealer said that Popp, while in England, mail
the IBM data disks to as many as 26,000 hospitals, businesses and
government agencies worldwide."
  "The disks claimed to provide information on AIDS prevention but at
the end of the computer program Popp allegedly said a computer virus
would be unleashed unless $378 was sent to a post office box in
Panama."

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Wednesday,  7 Feb 1990    Volume 3 : Issue 32

Today's Topics:

Checksums
Are virus sources public domain software ?
More about the 1260 virus (PC)
re: Universal virus detectors: Once more with feeling
Yankee Doodle Virus (PC)
Re: The 4096 virus (PC)
The V2000 virus (PC)
EDV Virus (New) (PC)
RE: AIDS... (Mac)
Killer Virus
Re: Universal Virus Scanner
VACSINA - the name (PC)
Identification strings
New Trojans (Mac)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

---------------------------------------------------------------------------

Date:    Sun, 04 Feb 90 13:56:00 -0500
From:    IA88000 <[e-mail]>
Subject: Checksums

This is an open question to anyone on the list who would care to
answer.

If you had your choice, which checksum routine would you consider most
secure, and why. If you do not want to reply on the list but would
rather reply by email, that's okay.

To make the question a little more specific, of the checksum routines
available today, which would you select.

------------------------------

Date:    Mon, 05 Feb 90 10:31:39 +0000
From:    [e-mail]
Subject: Are virus sources public domain software ?

In VIRUS-L, V3-I29, Todd Hooper (<[e-mail]>) writes:

> What possible technique could you use
> to make it illegal 'illegal to own or transmit virus code '? "

Well, how about some reliable organisation (the CERT, for example)
registering the source code under copyright laws ? Is virus code
considered as public domain software ? I wouldn't think so ! If the
source was copyright, then anyone having an unauthorized copy of it
would be in illegality. In fact, one might even say that the virus
itself is illegal on the grounds that it copies itself without
authorization. Anybody who feel they *NEED* to keep the source in
their possession should then also register or ask for authorization
from the organisation holding the copyright.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|Olivier M.J. Crepin-Leblond, Comp. Sys. & Elec. Eng    | On this computer,   |
|Electrical & Electronic Eng, King's College London, UK | a flame-proof       |
|BITNET  : <zdee699%elm.cc.kcl.ac.uk@ukacrl>            |  shield, is an      |
|INTERNET: <[e-mail]>| expensive gadget... |
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

------------------------------

Date:    Mon, 05 Feb 90 12:19:47 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: More about the 1260 virus (PC)

David Chess has just informed me of an interesting fact I missed in my
earlier note dealing with the 1260 virus.  If the encryption module is
removed, what is left is just a variant of the old and well-known
"Vienna" virus.

This variant is clearly derived from the version published in
"Computer Viruses: A high-tech disease".  The book is then responsible
for three viruses, because Lisbon and GhostBalls were also based on
that disassembly.

I have now disassembled the virus and a detailed description of it
will appear in the March issue of the Virus Bulletin.

My F-PROT package has been modified, and now it can detect and
disinfect "1260" and other viruses that use encryption methods with
permutations of the decoding instructions.

This new version (1.08) will be uploaded to SIMTEL tomorrow.  The bugs
found in 1.07 have also been fixed: One program (F-OSCHK) contained a
message in Icelandic, and another (F-DLOCK) interfered with CHKDSK and
some other programs.

Those of you who have asked me for a copy of F-PROT and not yet
received a reply - I will send you a copy of version 1.08 - sorry
about the delay.

Version 1.08 will also contain code to identify and remove the "new"
Bulgarian viruses.

- ------------------------------------------------------------------------------
frisk - Fridrik Skulason   University of Iceland, Computing Services.
                           Technical Editor, Virus Bulletin.

------------------------------

Date:    05 Feb 90 00:00:00 +0000
From:    "David.M..Chess" <[e-mail]>
Subject: re: Universal virus detectors: Once more with feeling

> David Chess continues, in essense, to complain about the user
> interface.

Not at all!  I'm saying that, no matter *what* the user interface
looks like, a system that relies on a human to decide whether or not a
timestamp-change is legitimate is no more a "universal virus detector"
than a program that relies on the user to type in the answers is a
"universal problem solver".

Jerry's point that most machines are not used for program development
is well-taken.  But the machines which -are- used for program
development are the ones where a virus could do the most damage (if I
buy a program that was infected with a virus "at the factory", the
fact that it can't spread any more on my machine isn't all that much
comfort).  It's also important to remember that "program development"
has to include writing BAT and CMD files, tailoring HyperCard cards,
and anything else which can effect, in a general-purpose way, how the
machine acts; taking that into account, many machines are used for
program development, and the proportion that are is likely to grow
rapidly as "programming" becomes easier.  It also becomes less clear
that an "is executable" bit is useable.  Would a Basic program be
marked as executable?  Would a shell script?

DC

------------------------------

Date:    Mon, 05 Feb 90 10:09:36 -0800
From:    [e-mail]
Subject: Yankee Doodle Virus (PC)

This is a forward from John McAfee:
=================================================================

        O. Fadel points out that Clean-Up overwrites files infected
with the Yankee Doodle virus and then deletes them rather than
removing the virus and repairing the program.  This is pointed out
clearly in the documentation.  Clean-Up V57 currently repairs
infections from 17 of the most common viruses (Yankee Doodle is by no
means a common virus - at least based on our reporting statistics) and
will identify and overwrite the remainder.  Each version of Clean-Up
will add more viruses to the list that we can repair - the remainder
we will still identify and overwrite.  Our priorities for inclusion in
the "repair" list are based on the frequency of virus reports.  We
hope to have all viruses included in the repair list by May 15.
Yankee Doodle is Scheduled for mid- April.
        Mr. Fadel asks why the Clean-Up delete function for less
common viruses is any better than the DOS delete function and why
anyone would bother to include it.  The answer is that the DOS delete
function, to the best of my memory, cannot search and identify an
infected file.  Neither does it do an overwrite.  (We overwrite with
C3H - the return function - so that a careless undelete will never
return the virus to your system).
        If Yankee Doodle is indeed a larger problem than we thought,
then we can re-arrange its priority and move it from the delete list
to the repair list for the next version.  I welcome suggestions.

John McAfee
408 988 3832 (Voice)
408 988 4004 (BBS)
408 970 9727 (FAX)

------------------------------

Date:    05 Feb 90 20:32:00 +0700
From:    [e-mail]
Subject: Re: The 4096 virus (PC)

In issue #27 John McAfee ([e-mail]) writes:

>        The virus is memory resident and infects COMMAND.COM, EXE
>files and COM files.  The virus initially places the machine in
>single-step mode and then issues an interrupt 21, sub-function 52 to
>determine the real address of the interrupt 21 code within DOS.
>Thereafter, it issues a long jump to that location to avoid any
>interrupt trapping antivirals that may be resident.  Thus the
>infection process, after the virus becomes resident, is transparent.
>        The strangest part of the virus is that it is also able to
>trap all other disk reads and writes, and whenever an infected file is
>accessed by any program, the virus performs a disinfection of the
>program on the fly.  Thus checksumming techniques, file length checks,
>and other file modification detectors cannot perceive the infection on
>the disk.  Even searching the disk for the specific virus code will
>fail, since the code is removed from the file during the read request.

I was sure that somewhen someone of the virus writers out there would
have the same idea! The latest versions of the Bulgarian TP viruses
perform exactly in the same way! (The 4096 virus however is not known
in Bulgaria.) I purposely didn't discuss in deep these techniques but
I see now that this was useless --- someone had already reinvented
them. Too sad...

By the way, I have some general questions about viruses:

        (1). Which of the known viruses will run under OS/2? I mean
             exactly OS/2, not its DOS 3.3 compatibility box.
        (2). Does anybody know something about a VAX/VMS virus which,
             when activated, slows down the data exchange with the
             terminals (something about 3 bps)? There were some rumors
             about such virus in Bulgaria, but I've never seen a
             working copy.

------------------------------

Date:    02 Feb 90 10:49:00 +0700
From:    [e-mail]
Subject: The V2000 virus (PC)

                           The V2000 Virus
                           ---------------

        This virus is also "made in Bulgaria" and again I am
indirectly the cause of its creation.  I am a well known
"virus-buster" in Bulgaria and my antivirus programs are very widely
used.  Of course, virus designers didn't like it.  So their next
creation...  causes trouble to my antivirus programs.

        This virus is exactly 2000 bytes long and I think that it was
created by the author of the Eddie (Dark Avenger) virus.  The
programming style is the same and there are even pieces of code which
are the same.

        The virus acts much like the Eddie one --- it installs
resident in memory by manipulating the memory control blocks; infects
COMMAND.COM at the first run; infects both .COM- and .EXE-files;
infects files when one executes them as well as when one copies them.

        However, there are some extras added.  First, the virus is
able to fetch the original INT 13h vector just like the V512 one (by
using the same undocumented function --- tricks spread fast between
virus programmers).

        Second, it intercepts the find-first (FCB) and find-next (FCB)
functions --- just like V651 (and contains the same bugs), so you
won't see the increased file lengths in the listing displayed by the
DIR command.

        Third, it contains the string "Copyright (C) 1989 by Vesselin
Bontchev", so people may think that I am the author of this virus.  In
fact, the virus searches every program being executed for this string
(the case of the letters does not matter) and if found, hangs the
system.  It is not necessary to tell you that all my antivirus
programs contain this string.  Of course, now I will have to use some
kind of encryption, just to prevent such tricks.


                        Sincerely,
                                         Vesselin

------------------------------

Date:    Mon, 05 Feb 90 15:19:09 -0800
From:    [e-mail]
Subject: EDV Virus (New) (PC)

This is a forward from John McAfee:

=================================================================

        Dave Chess sent us another new virus that uses "creative"
techniques to avoid detection from scanning type programs.  Dave calls
it the EDV virus.  The virus infects boot sectors of floppy diskettes
and the partition table (master boot record) of hard disks -- similar
to the stoned virus.  It saves the original boot sector and if any
program attempts to read the boot sector, the virus intercepts the
read and retrieves the original boot sector instead.  Thus the system
will appear normal even if infected.  This technique is not new.  The
Pakistani Brain was the first virus to use this avoidance technique.
        What is new about this virus is that it also avoids detection
from a memory scan.  The virus accomplishes this feat by intercepting
the clock tic and at each tic the virus interrogates ES and DS to
determine if anyone is looking at the virus code.  If someone is
looking, the virus hangs the system.
        All these new detection avoidance techniques can of course be
circumvented.  They do require development time, however, and are
becoming a nuisance.  We have opted in SCAN not to block the timer
interrupt (the obvious bypass to circumvent this virus) due to
potential problems with time dependent background code.  Instead,
we've chosen to outrun the virus using our own "creative" memory scan.
Seems to work so far and will be included in V58 of SCAN - - due out
Feb 15th -- if beta testing goes well.

John McAfee  ...................

------------------------------

Date:    Mon, 05 Feb 90 20:50:21 -0500
From:    woodb!scsmo1![e-mail]
Subject: RE: AIDS... (Mac)

I don't think that I have seen this question but...

Did the AIDS virus really contain ANY information on AIDS or any REAL
non-virus program?

- --
 DON INGLI-United States Department of Agriculture - Soil Conservation Service
 INTERNET: scsmo1![e-mail]    PHONEnet: 314!875!5344
 UUCP(short): uunet!scsmo1!don        UUCP(long): uunet!mimsy!woodb!scsmo1!don
              These are my opinions. I represent myself.
   Who do you think you are, Bjorn Nitmo?  David Letterman '90 Catch Phrase

------------------------------

Date:    05 Feb 90 21:07:52 +0000
From:    [e-mail] (James Reeves)
Subject: Killer Virus

I have just finished disassembling a virus that was found in our
company that is called KILLER DISK by Computer OGRE. If anyone has been
infected by this virus drop me a line. I have written a program that
will detect and remove the virus from any floppy or hard disk. In
addition I have extracted the algorithm neccessary to undo the damage
if the virus attacks the hard disk. The virus takes about 48 hours
of computer use before attacking. In the mean time it transfers itself
to ANY floppy that is read or written from the infected machine.

If anyone has any comments or questions please let me know.


Thanks
James Reeves

------------------------------

Date:    06 Feb 90 09:31:28 +0000
From:    [e-mail] (Christian Wettergren)
Subject: Re: Universal Virus Scanner

I think that the discussion about an Universal Virus Scanner is very
intresting but is it even possible to conclude that a program doesn't
modify itself?

What I mean is that I don't think that you could create a program that
could say YES, this program modifies itself, or NO, this program
doesn't modify itself.

That depends of course of what microprocessor you use. On an ordinary
8086 you couldn't, I think. Imagine this;

The program has an instruction that contains a reference to it's own code-
adress. ( MOV CS:0199h, XXXX )
OK, then don't tolerate that.
But what if it calculates it from a formula? ( MOV CS:[BX], XXXX )
Then don't tolerate a reference that uses a CS-prefix.
But the same adress is reachable from perhaps some Data Segment.
( MOV DS:1238h, XXXX )
OK, then don't tolerate direct references to the code through a Data
Segment But what if it is calculated through a formula? ........
( MOV DS:[BX], XXXX )
Then don't tolerate writes at all.... 8-)

Of course some micros could prohibit this behavior by some sort of
MMU-scheme, but I think that at least 8086 and 68000 (not so sure
there, though) couldn't contain an algorithm that could determine if
the program was self-modifying or not. (Of course it could contain it,
but it would have to be simulating the micro itself, and hence has the
same problem there, etc)

Christian Wettergren [e-mail]
Royal Institute of Technology, Stockholm, Sweden

------------------------------

Date:    Tue, 06 Feb 90 10:20:11 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: VACSINA - the name (PC)

Some time ago there was a bit of discussion here on Virus-L, regarding the
virus name VACSINA.

According to Vesselin Bontchev - the Bulgarian virus researcher, there
is a logical explanation for the name - which is the Bulgarian word
for "vaccine".

VACSINA is the logical name of a device-driver virus-protection program,
written by the same person as wrote the virus. Since the virus communicates
with this program, the string VACSINA appears in the virus.

The full decription of the "VACSINA" virus (as well as the other 30-50
Bulgarian virus variants) will probably be posted by Vassilian soon.

- ------------------------------------------------------------------------------
frisk - Fridrik Skulason - University of Iceland, Computing Services
                           Technical Editor, Virus Bulletin


------------------------------

Date:    Tue, 06 Feb 90 10:47:37 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Identification strings

I have been comparing a few little-known virus-detection programs
recently.  There is a problem with some of the less well known
programs, namely that they may appear as infected to some of the other
anti-virus programs.

The reason is that they sometimes store a virus identification string
in unmodified form, and in the case of the shorter viruses, two
programs may have picked the same identification string, which may
cause them to appear as infected to one another.

So - you anti-virus writers out there: Please store identification
strings encrypted, reversed or somehow modified.

Another subject - there is some confusion regarding the terms
"identification string" vs. "signature strings". How about:

        Identification string: A sequence of bytes, used by anti-virus
        programs to check if a program is infected.

        Signature string: A sequence of bytes, used by the virus to check
        if a program is infected.

Comments ?

Fridrik Skulason   -   University of Iceland, Computing Services.
[e-mail]        Technical Editor, Virus Bulletin.

------------------------------

Date:    06 Feb 90 08:56:00 -0500
From:    "WARTHMAN" <[e-mail]>
Subject: New Trojans (Mac)

Peter Johnston posted information about two strains of a new trojan
which can damage the Macintosh file system. One strain exists in a
program called "Mosaic" and the other in a program called
"FontFinder". I'd like to know if anyone else has had experience with
these two trojans, and which of the existing commercial and public
domain anti-virus tools can detect/prevent them from doing their
damage. Since the "FontFinder" trojan has a trigger date of 10 Feb,
it's important that we quickly publicize this trojan's effects and
countermeasures.  Thanks in advance.

 --- Jim Warthman

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Wednesday,  7 Feb 1990    Volume 3 : Issue 33

Today's Topics:

WDEF in Toronto (MAC)
GateKeeper Aid on AppleShare Server (Mac)
Idea for WDEF Innoculation (Mac)
Disinfectant 1.6 (Mac)
Advice for cluster managers
The V-847 virus (PC)
WDEF A (Mac)
"Mosaic" and "FontFinder" Trojan (MAC)
Viruses 4096 and 1260 on BBS (PC)
RE: Trojan Alert (MAC)
More about WDEF
WDEF Virus (Mac)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

---------------------------------------------------------------------------

Date:    Tue, 06 Feb 90 09:05:42 -0500
From:    "Kevin Adams" <[e-mail]>
Subject: WDEF in Toronto (MAC)

Humber College in Toronto has been hit by the WDEF virus.  We first
detected it when machines began crashing (mouse still moved cursor
around the screen, but no other response).   It had managed to infect
the desktop of our server by the time we caught up with it..
We had resident virus protection in place, but it was too old to
snag WDEF.

We brought it under control with Disinfect 1.5 and Eradicat'Em.  We
tried Gatekeeper Aid prior to Eradicate'Em,  but it seemed not to work
on our IIcx's and SE30's.

We've also survived NVIR A and NVIR B.

>From the reports I've read NVIR and WDEF both have no malicious
intent, and that any damage they cause are 'side effects'.  Is this
accurate?

It seems very strange to me that Virus writers would launch
their missiles with no payload...

Kevin Adams
User Services Group
Humber College of Applied Arts and Technology

------------------------------

Date:    Tue, 06 Feb 90 11:23:00 -0500
From:    Roberta Russell <[e-mail]>
Subject: GateKeeper Aid on AppleShare Server (Mac)

I installed Gatekeeper Aid on our AppleShare File and Print Server
today.  When I rebooted the server, I got the message "GateKeeper Aid
encountered FCB expansion."  Can someone tell me what this means?
Thanks,

Roberta Russell
Academic Computing, Oberlin College
[e-mail]
[e-mail]

------------------------------

Date:    Tue, 06 Feb 90 12:23:51 -0500
From:    Jason Ari Goldstein <[e-mail]>
Subject: Idea for WDEF Innoculation (Mac)

Just like everywhere else the WDEF is thriving here at Carnegie-Mellon
Univ.  I recently removed WDEF A & B off of 15 disks of a friend of
mine.  When I commented to somone here about the virus they said there
was nothing they could do to stop it, except remove it once a machine
got infected.

I don't know much about Macs (Being a PC person) but if I understand
correctly every time the disk is inserted the they Virus is sread to
the disk.  Well, why doesn't someone write an innoculation directly
based on the virus itself.  Everytime a disk is inserted in the drive
it would be checked for infection if so it would remove WDEF if not it
would then 'innoculate the disk' with itself.  Eventually, WDEF would
be wiped out the same way it was spread initially.

The only problem with this is that it is a virus also, but with the
proper prompts (allowing the user the choice of being innoculated) I
don't think this would be a problem.  I know I would mind not ever
being infected by a virus that kills other viruses.

In the mean time, about 75% of the time I in a cluster I remove WDEF A
or B from either a hard disk or someone elses floppies.

Later...

me
- -------------------
Jason Goldstein
Internet:  [e-mail]
Disclaimer: I represent me and only me not CMU, not my folks, not anyone.

"Thank the lord my PC came in the mail yesterday" - me

Over, Finished, Gone, Done, Out.

------------------------------

Date:    Tue, 06 Feb 90 12:58:46 -0600
From:    Fung P Lau <[e-mail]>
Subject: Disinfectant 1.6 (Mac)

     I have recently read something about Disinfectant 1.6 from this
newsgroup.  Its author said that there was no Disinfectant 1.6 and it
maigt cause potential porblems on virus detection.  Someone in our lab
downloaded it and has been using it without any obvious trouble.  I
would appreciate any further comments on this application.  So, again,
is there any upgraded version of Disinfectant after version 1.5 ?  If
not, is there any more information about this "fake" Disinfectant ?

------------------------------

Date:    Tue, 06 Feb 90 14:36:30 -0600
From:    Meesh <[e-mail]>
Subject: Advice for cluster managers

I'm preparing a guide to microcomputer cluster security for the
microcluster managers here at the Univ. of Houston.  What kind of
information would you want to see in such a publication?  What kind of
advice would you offer to someone who's just setting up a cluster?

Send replies to me:     [e-mail]
                        [e-mail]

Michelle M. Gardner
Coordinator, Computing Information Services
Information Technology Division


------------------------------

Date:    06 Feb 90 16:57:00 +0700
From:    [e-mail]
Subject: The V-847 virus (PC)

                          The V-847 Viruses
                          -----------------

        This virus was imported in Bulgaria by foreigner student from
Greece.  He claimed that the virus code was created and published by
the PIXEL magazine.  The virus is supplied as a program in BASIC,
which when run creates a .COM-file which in fact contains the real
virus.

        The virus is extremely stupid. It infects only .COM-files in
the current directory of the current drive. However, it infects *all*
these files at once. The only way to spread the virus is to run an
infected file when one of the directories listed in the PATH variable
is current. Then each time a file from this directory is run, all
files in the current directory will get infected.

        The virus is not memory resident. It becomes active only when
an infected file is run.

        The virus *prepends* itself in front of the infected files.
Their size increases by 847 bytes, most of which contain garbage. Each
infected file contains the generation number of the virus. There are
no effects before the 5th generation. After the 5th generation
however, when you attempt to execute an infected file, you will
succeed with probability of only 1/2 (the lowest bit of the system
timer is used as a random number generator). If the chances are
against you, you will receive the message:

"Program sick error:Call doctor or buy PIXEL for cure description"

and the program will terminate.

        This virus was also hacked a bit.  There are two known
mutations in Bulgaria, however they are not widely spread.  In fact,
they are very rare.  The first is optimized and is 345 bytes long.
The second is even more optimized.  Its length is only 299 bytes.


------------------------------

Date:    Tue, 06 Feb 90 16:46:51 -0600
From:    "James N. Bradley" <[e-mail]>
Subject: WDEF A (Mac)

Today, while I was disinfecting a Macintosh IIx with Disinfectant 1.6
I got a report saying that the desktop was infected at 3:36 p.m. on
2/6.

Now, it just happened that it WAS 3:36 p.m. while I was doing the
disinfecting.

I was using a locked disk which checked clean both with Disinfectant
1.6 and Gatekeeper Aid.

Since the locked disk was clean, it couldn't have infected the HD,
right?  The person involved swears that no other disks had been in his
drives today.

Any ideas?
Jim Bradley
Acknowledge-To: <ACSH@UHUPVM1>

------------------------------

Date:    Tue, 06 Feb 90 15:01:22 -0700
From:    Peter Johnston <[e-mail]>
Subject: "Mosaic" and "FontFinder" Trojan (MAC)

Since my first posting of the two trojans we have detected here at the
University of Alberta, a few things have occurred.  This update is an
attempt to share what we have learned so far:

On a suggestion from Paul Cozza, we determined that both the trojans
we detected are stopped by SAM (Symantec Anti-viral for the Macintosh)
Intercept.  The version tested was quite an old one, but Paul suggests
that all commercially released versions should also stop the trojan
from doing its nastiness.  When we tested SAM, the Mac was invariably
left hung when we "Denied" the permission SAM was requesting, but upon
re-booting, the disks were found to be undamaged.

Several of the anti-viral software developers have contacted us for
further information on this trojan, and we have assisted them wherever
possible.  I would expect versions of many of their packages able to
detect this trojan to start appearing in the near future.

I have received as of this date no reports of infection from any other
sites.  Remember, though the trigger date of 10 Feb 90.  I'll feel a
little more relaxed after that date.

University Computing Systems has prepared a client hand-out that
describes in relatively non-technical terms what both of these trojans
do and what users can do to combat them.  Unfortunately, a lot of the
information is specific to the University of Alberta, but if anyone is
interested, we would be pleased to provide copies of both for your
use, or upload them to VIRUS-L, depending on the demand.  Please
contact me if this would be of assistance to you.

We are continuing our investigations, and will report additional
information as we uncover it.  You will also likely start receiving
informational reports from some of the anti-viral software developers
as to the internal characteristics and structure of these trojans.

The one gratifying aspect of this whole episode is the speed with
which the warning was spread, and the prompt and professional response
we here in the far north received from the anti-virus community as a
whole.  This trojan is dangerous, no question about it.  But not
nearly as dangerous as a full fledged viral version having the same
type of destructive tendancies.  Having a mechanism in place to react
to these attacks is a pretty powerful deterrant force.

In the meantime, please continue to recommend that your Mac users make
regular backups and to practice "safe computing".  I still feel that
user education is one of the most powerful weapons we have to combat
malicious code attacks...

Peter Johnston, P. Eng.
Senior Analyst, University Computing Systems,
352 - GenSvcBldg, The University of Alberta
Edmonton, Alberta CANADA    T6G 2H1
Phone: [phone]
FAX: [phone]
EMAIL: [e-mail]

------------------------------

Date:    Tue, 06 Feb 90 22:57:40 -0400
From:    GEORGE SVETLICHNY <[e-mail]>
Subject: Viruses 4096 and 1260 on BBS (PC)

 In Virus-L v3 issue31, [e-mail] (David Dyer-Bennet) writes
 concerning the 4096 and 1260 viruses:

>John McAfee writes:
>:      The strangest part of the virus is that it is also able to
>:trap all other disk reads and writes, and whenever an infected file is
>:accessed by any program, the virus performs a disinfection of the
>:program on the fly.
>  infected file?
>
>As a BBS sysop, I find this a particularly amusing feature: it assures
>my users that anything downloaded from my BBS is not infected with
>this class of virus!  The concept of BBS's as *the safest* source of
>software (at least in this one regard) is rather amusing.

What David forgets to mention is that the BBS is the safest source of
virus-free files *as long as the BBS is infected* with these viruses.
Will Sysops now start deliberately infecting their boards with these
viruses so as to assure the users clean files? Is your BBS infected,
Dave? ;-)

 ----------------------------------------------------------------------
 George Svetlichny                 |
 Department of Mathematics         |
 Pontificia Universidade Catolica  |  So it goes.....
 Rio de Janeiro, Brasil            |    Kurt Vonnegut Jr.
                                   |
 [e-mail] Fido 4:4/998 |
 ----------------------------------------------------------------------

------------------------------

Date:    Tue, 06 Feb 90 22:21:23 +0000
From:    <[e-mail]>
Subject: RE: Trojan Alert (MAC)

One real quick question about this new Mac virus. Do any other
programs detect it (i.e.Virus Rx, Interferon, etc.)? And what versions
if any are you using to detect it?

Thanks,

Ed Vasko

------------------------------

Date:    07 Feb 90 06:03:18 +0000
From:    [e-mail] (Wing Leung)
Subject: More about WDEF

        Can someone tell me is WDEF an illegal string in the resource code?
How about the program called WDEF uploaded in comp.binaries.mac?
        In fact, I've found some WDEF resource code in system version 6.0.3.
        Please tell me more about this resource code.

Peter

- --
  _    _  ____  ____   _        * Internet:     [e-mail]
 (/   /  //  / //   ) (/        * BITNET  :     WCPL_LTD@UORDBV
 / / /  //    //___/ _/         * DecNet  :     UORHEP::PETER
/_/_/  //__/ //     _/\___/     * UUCP    :     ...rochester!uhura!wcpl_ltd

------------------------------

Date:    Wed, 07 Feb 90 08:59:00 -0500
From:    [e-mail]
Subject: WDEF Virus (Mac)

I have been away from my office and my macintosh network for three
months and when I come back and read my bitnet messages I see there is
a new virus call WDEF.  Can I get some info on this.  What virus
detectors can I use to check out my network?  How can it be
eradicated?  What are its characteristics?  Please send your response
directly to me.

Thanks a bunch.

Salonge Crenshaw
University of Richmond
Richmond, VA  23173
Bitnet: Moses@URvax
Phone : [phone]

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Thursday,  8 Feb 1990    Volume 3 : Issue 34

Today's Topics:

AIDS Virus (Mac) and AIDS Trojan (Non-Mac)
WDEF-A arrives at Smith College (Massachusetts) (Mac)
Re: Are virus sources public domain software ?
Re: Virus Modeling
Mac Virus Harmlessness
WDEF, WDEF, WDEF (Mac)
W/1813 Virus (PC)
Anyone heard of the SYSLOCK virus? (PC)
Other progs identify trojans? (Mac)
copyrighting virus code
More about 847 (PC)
More on the new Mac Trojans

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

---------------------------------------------------------------------------

Date:    Wed, 07 Feb 90 13:58:10 -0500
From:    Joe McMahon <[e-mail]>
Subject: AIDS Virus (Mac) and AIDS Trojan (Non-Mac)

There is a Mac virus named AIDS. It's an nVIR-b clone (i.e., the
resources and code were modified to use resources of that name instead
of "nVIR").  It does the same stuff that nVIR does - i.e., reproduce
and sometimes beep when a program is launched. It does nothing
connected with the disease.

The non-Mac "AIDS Disk" being talked about lately is NOT connected
with the Mac at all. It was a program that purported to be a survey
which would tell you how much of a risk you had of contracting the
(non-computer) virus. It instead encrypted all of your files and
attempted to get you to mail $300-and-some to an address in Panama.

Clear?

 --- Joe M.

------------------------------

Date:    Wed, 07 Feb 90 13:52:00 -0500
From:    [e-mail]
Subject: WDEF-A arrives at Smith College (Massachusetts) (Mac)

Our one and only Mac lab became infected with WDEF-A this past weekend.

Many thanks to John Norstad, Chris Johnson, and others for providing
tools to fight these things!

Peggy Shannon
Center for Academic Computing
Smith College
Northampton, Massachusetts
[e-mail]

------------------------------

Date:    Wed, 07 Feb 90 13:57:28 -0600
From:    [e-mail] (James R. B. Davies)
Subject: Re: Are virus sources public domain software ?

[e-mail] writes:
> From: [e-mail]
> Subject: Are virus sources public domain software ?
> Date: 5 Feb 90 10:31:39 GMT
>
> In VIRUS-L, V3-I29, Todd Hooper (<[e-mail]>) writes:
> > What possible technique could you use
> > to make it illegal 'illegal to own or transmit virus code '? "
>
> Well, how about some reliable organisation (the CERT, for example)
> registering the source code under copyright laws ? Is virus code
> considered as public domain software ? I wouldn't think so ! If the
> source was copyright, then anyone having an unauthorized copy of it
> would be in illegality. In fact, one might even say that the virus
> itself is illegal on the grounds that it copies itself without
> authorization. Anybody who feel they *NEED* to keep the source in
> their possession should then also register or ask for authorization
> from the organisation holding the copyright.
>
> Olivier M.J. Crepin-Leblond

No, in order to register a copyright you must be the author of the work,
or have the rights explicitly assigned to you by the author.
(I wouldn't consider an organization reliable if they WERE the authors,
would you?)

I suspect that there is no good legal solution for the virus problem.
People who create viruses don't expect to get caught, and probably
wouldn't be deterred by the threat of legal sanctions.  Also, it would
be an immense problem to prove who first released a virus in most (if
not all) cases.  For example, the Internet worm case was not quite
open-and-shut, despite the following unusual facts:
   1. The defendant admitted under oath that he did it
   2. There was a law which explicitly forbade what he did
          (i.e. unauthorized access to government computers with damage)

I would venture to guess that there are very few known virus authors out
there, even for the oldest, most widespread varieties.  The Brain virus
seems to be the exception, but even in that case it would be a nightmare
to try to prosecute the perpetrators.

------------------------------

Date:    Wed, 07 Feb 90 19:41:17 +0000
From:    [e-mail]
Subject: Re: Virus Modeling

[e-mail] (Greg Fife) writes:
> [e-mail] writes:
>>                                        As someone pointed out, a real
>>computer isn't a finite state machine because it includes the person
>>operating it
>
> A human being may or may not be a finite state machine, but the
> effect he he has on a computer system is merely to add a finite
> number of transitions to the computer. (Striking one of the finite
> number of keys changes the interrupt state on a PC, putting in
> a new disk changes many of the bits on that mass storage device).
>
> You can't model exactly which inputs the human will provide, but
> you can reason about behavior under any possible set of inputs.
> In effect, a person at a computer is running a huge finite
> automata through an input string consisting of his actions.
>
> Take the initial state to be one of the finite number of
> states which represents the introduction of the virus into
> the system.  Mark the finite number of states which represent
> "infection" as final states.  The question: "can infection occur"
> is merely the question "does this FA have a nonempty language."
> That question can be settled in finite time by testing the FA
> on every input string of length less than or equal to the number
> of states in the FA.  Do this once for every initial "infection"
> state, and the result follows. :-)

Take a binary file editor. Or an interactive assembler. Or uudecode
reading from stdin. Any of these programs will take input from the
user and based on this input can reach most of the possible states of
the system, including those in which replication of the program can
occur. (I'm using "almost" in a loose sense: 2^990,000 is almost
2^1,000,000). So are these viruses? By your rationale they are. Or a
terminal emulator which based on input from the outside world could
cause infection (it could download an infected program from a bulletin
board). And what about a worm program that transmits itself to another
machine but does not infect other programs on the current machine?

Having said that, your method would be OK for most software, if you
only want to check for viruses not worms.

"To summarize the summary of the summary: people are a problem"
Russell Wallace, Trinity College, Dublin
[e-mail]

------------------------------

Date:    Wed, 07 Feb 90 16:32:24 -0500
From:    Joe McMahon <[e-mail]>
Subject: Mac Virus Harmlessness

It's interesting, but up until now, most viruses on the Mac have been
"damageless" - the only reason the cause trouble is because of bugs
and incompatabilities, not deliberately harmful code. nVIR, at worst,
causes your Mac to beep in some cases (side effects are worse -
crashes, hangs, printing failures).

Perhaps we just haven't had the right (wrong?) people writing Mac
viruses so far. Any ideas?

 --- Joe M.

------------------------------

Date:    Wed, 07 Feb 90 16:38:46 -0500
From:    Joe McMahon <[e-mail]>
Subject: WDEF, WDEF, WDEF (Mac)

>From:    Jason Ari Goldstein <[e-mail]>
>
>Just like everywhere else the WDEF is thriving here at Carnegie-Mellon
>Univ.  I recently removed WDEF A & B off of 15 disks of a friend of
>mine.  When I commented to somone here about the virus they said there
>was nothing they could do to stop it, except remove it once a machine
>got infected.

Eradicate'em and Gatekeeper Aid both stop the virus and automatically
remove it from the disk as disks are inserted.

>I don't know much about Macs (Being a PC person) but if I understand
>correctly every time the disk is inserted the they Virus is spread to
>the disk...

Close enough; the default window definition procedure also has to be
invoked, and you have to be running under the Finder.

>Well, why doesn't someone write an innoculation directly
>based on the virus itself....
>The only problem with this is that it is a virus also, but with the
>proper prompts (allowing the user the choice of being innoculated) I
>don't think this would be a problem....

It might not be a problem on current Macs or current versions of the
System, but would be very likely to fail in future incarnations.
Also, available anti-virals probably wouldn't be able to tell the
difference between your "WDEF C" and a real infection, so well-meaning
disinfectors would wipe out your "inoculation". Finally, I think we
all agree that viruses to fight viruses simply help to continue the
upward spiral of virus technology, and that *any* virus has the
potential to cause damage under some circumstances. Worse, a virus
writer could take your supposedly harmless virus and hack it into a
virulent one. If your anti-virus virus contains your name, you might
have trouble convincing people (including law enforcement) that you
didn't write the nasy variant.

>In the mean time, about 75% of the time I in a cluster I remove WDEF A
>or B from either a hard disk or someone elses floppies.

Jason, if no one there has the programs I mentioned above, they are
available from our LISTSERV. Worst case, there is a very simple way
of getting rid of WDEF infections, and it's BUILT IN to the Mac!

When you insert a disk, hold down the Command and Option keys. You'll
get a message asking if you want to rebuild the Desktop file. Click "OK".
This will blow away any existing WDEF infection. The same can be done
for boot disks: just hold down those two keys after the "Welcome to
Macintosh" screen appears. You'll get the same dialog, to which you
respond in the same way. Nothing could be simpler. Rebuilding the
Desktop causes it to be thrown away, virus and all, and a new copy
built. Since WDEF doesn't live anywhere else, you're all set.

>From:    Fung P Lau <[e-mail]>
>
>     I have recently read something about Disinfectant 1.6 from this
>newsgroup.  Its author said that there was no Disinfectant 1.6...

At the time the message was posted, that was true. John Norstad created
1.6 since then, so versions of that program from sumex, John's node, or
the SCFVM LISTSERV are true, valid copies of Disinfectant 1.6.

>From:    [e-mail] (Wing Leung)
>
> Can someone tell me is WDEF an illegal string in the resource code?

WDEF resources are "window definition procedure" resources. They define
how windows look and act. They are legal.

>How about the program called WDEF uploaded in comp.binaries.mac?

It's an alternate window definition procedure and is OK.

>In fact, I've found some WDEF resource code in system version 6.0.3.
>        Please tell me more about this resource code.

That's the code that defines the standard Mac window (scroll bars,
go-away box, zoom box, etc). DON'T DELETE IT or your System file will
no longer be usable.

Whew.

 --- Joe M.

------------------------------

Date:    Wed, 07 Feb 90 15:16:15 +0000
From:    [e-mail] (Mike Mize)
Subject: W/1813 Virus (PC)

I'm looking for info regarding the W/1813 virus.  It seems that a PC
in one our campus labs is infected and we can't get rid of the virus.
Could someone please mail me info on symptoms and iradication methods
for this virus.  I would greatly appreciate it.

|\  /|       |               |     : Michael Mize
| \/ | *  __ |__   __    __  |     : C. S. U., Fresno  MS 93
|    | | |   |  | |  |  |__| |     : Fresno, Ca. 93740
|    | | |__ |  | |__|_ |__  |_    : [e-mail]

------------------------------

Date:    Tue, 06 Feb 90 15:46:15 +0000
From:    [e-mail]
Subject: Anyone heard of the SYSLOCK virus? (PC)

I'm posting this request on behalf of a friend who doesn't have access
to news.  Also, I don't always read this newsgroup, so please mail any
replies direct to me. If there is sufficient response, I will
summarise to the net.

The subject line says it all really...does anyone know anything about
the so- called "SYSLOCK" virus, and in particular, how it works, how
to get rid of it?  It has been discovered on "Compaq 286 & 386's and
PS2/30 + 20Mb HD". All my friend knows about it is that it appears to
add ~3500 bytes to files and spreads quickly!

Any help anyone could give would be much appreciated!

Thanks in advance,

John

===============================================================================
John Cullen                     || JANET : [e-mail]
System Support Group            || ARPA  : [e-mail]
Informatics Department          || BITNET: jjsc%uk.ac.rl.inf@ukacrl
Rutherford Appleton Laboratory  || UUCP  : {...!mcvax}!ukc!rlinf!jjsc
Chilton, Didcot, Oxon. OX11 0QX || VOICE : [phone] ext 5739
===============================================================================

------------------------------

Date:    Wed, 07 Feb 90 16:38:58 -0700
From:    Peter Johnston <[e-mail]>
Subject: Other progs identify trojans? (Mac)

To the best of my knowledge, only SAM and the VD string I specified
will identify these two trojans at the present time. I would assume
that the anti-viral software developers will be updating their
products fairly quickly, and would expect to see announcements fairly
quickly though.

One point I would like to re-iterate, as several people have contacted
me about it and I may not have been very clear in my original posting:
Neither the "Mosaic" nor the "FontFinder" trojans are viruses. Neither
has the ability to reproduce or self-propigate. The only way that
either of these applications can be duplicated is by a user copying
the file, or by up/down-loading the files to/from a BBS...
 - - - - - - - - - - - - - - - - - - - - - - - - - -
 Peter Johnston, Senior Analyst,
 University Computing Systems, 352 - GenSvcBldg,
 The University of Alberta, Edmonton, Alberta, CANADA
 Voice: 403/492-2462        Bitnet: USERGOLD@UALTAMTS
 - - - - - - - - - - - - - - - - - - - - - - - - - -

------------------------------

Date:    Wed, 07 Feb 90 18:49:30 -0500
From:    Steven C Woronick <[e-mail]>
Subject: copyrighting virus code

M.J. Crepin-LeBlond <[e-mail]> suggests that all you
have to do to make having virus code illegal (except for the
privileged few who obtain permission) is to copyright it.  I'm no
lawyer, but it was my impression that once something has been released
in some form (uncopyrighted) to the general public, it could then
never be copyrighted.  Even if you could copyright viral code, it's
not likely to discourage the kind of people who write viruses (aren't
those the ones you are really after?) from copying it.  Also, what
happens if some virus-loving person copyrights it before you do and
then grants universal privilege to copy?  Just wondering...


------------------------------

Date:    Thu, 08 Feb 90 08:18:57 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: More about 847 (PC)

The "Bulgarian" 847 virus is closely related to the Amstrad virus.
They are not identical, however. The text is different, and some minor
changes have been made to the code.

It is however so similar that existing virus scanners can detect any
program infected with "847" (PIXEL), "345" or "299".

- -frisk

------------------------------

Date:    07 Feb 90 22:15:00 -0800
From:    [e-mail]
Subject: More on the new Mac Trojans

More on the new Mac Trojans:

In response to Peter Johnston's message about the Trojans Mosaic and
FontFinder, I'd like to add a few things:

The Trojans hang (whether or not SAM denied the write attempt) due to
a bug in the code. When the bug is 'fixed', Mosaic goes on to give
further information to the user about what it has done.

As Peter mentioned, disks ARE undamaged if the Trojans' write attempt
is denied in SAM. All versions of SAM will alert you to this write
attempt with the message 'There is an attempt to bypass the file
system'. HOWEVER, this alert will only be given to the user if SAM is
configured in ADVANCED level.

Again, the best protection, as always, is to be sure your files are
backed up!

Paul Cozza

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Friday,  9 Feb 1990    Volume 3 : Issue 35

Today's Topics:

There is no Ultimate Anti-Viral Solution!
More general questions about known viruses (PC)
Re: Identification strings
Towards a programmable virus scanner/cleaner
Re: GateKeeper Aid on AppleShare Server (Mac)
WDEF & rebuilding the desktop (MAC)
My Jerusalem B nightmare! (PC)
Gates of Hades ? (PC)
Virus insurance offered
Novell network virus ??? (PC)
Re: More about 847 (PC)
F-PROT Question (PC)
Disinfectant 1.6 (Mac)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

---------------------------------------------------------------------------

Date:    06 Feb 90 01:40:05 +0000
From:    [e-mail] (Robert I. Eachus)
Subject: There is no Ultimate Anti-Viral Solution!

     I read this group to keep track of potential new virus that I may
have to deal with, but there has been a lot of wasted bandwidth on
whether or not some scheme or other will prevent viruses.  If you are
thoroughly convinced of this, press n now.

     For the rest of you: There are three classes of unsolved
problems: First, there are those which are theorically soluble, but
are, to the best of anyone's current knowledge, infeasable in
practice.  The second group is those problems which are provably
infeasible.  The third group is problems which have been proven
insoluble using any type of solution, imaginable or otherwise.  This
group includes problems like the Post Correspondence Problem, the
Halting problem, and universal virus detectors.

     Note that there are NO qualifications about the third group which
allow anyone to hope that ANY problem in the third group is amenable
to practical (as opposed to theoretical) workarounds.  Realize that
any assumptions about what a virus author will or won't do have to
assume that he or she is a "determined adversary" who will take every
opportunity to make things difficult for virus detectors.  It is easy to
show that "prior" detection of virus programs, or detection of all
virus programs is in the third group.  It is more complicated, but not
significantly more difficult to show that any universal viral detector
(UVD from here on...) must define its own counterexample, just like
the flask of universal solvent, and that virus authors will be able to
take advantage of this.

     (Since this is directed at some unspecified group of
unintelligent people, not at YOU, I feel compelled to explain that
last remark. :-) It is impossible to have a FLASK which can contain a
universal solvent, if a universal solvent exists.

     Similarly, if I had the magical UVD that some people think can
exist, I can create from it a virus that it cannot detect!  If you
don't understand this go read "Godel, Escher, Bach" by D. Hofstater,
or any other lucid explanation of what Godel's Proof means, then if
you still don't understand it, try the following...

     A month later already?  Oh, you skipped GEB.  No fair!  Go back
and read it, or give up your right to flame me because you don't
understand the terminology.

     Assume that I have a UVD that allows useful programs to execute,
including scripts and interpreted programs, etc. while blocking (or
detecting) all viruses.  A program which blocks all, not just useful
programs, from executing is easy to write and is usually called a
virus of a Trojan horse.  (No, I take that back--it is called a lot of
things, one of the printable things such a program is called is a
virus.)  The UVD on the other hand, would certainly fit the definition
of a useful program, so it must allow itself (and programs equivalent
to itself) to execute.  For any UVD there will be a class of programs
which for which it is undecideable whether they are equivalent to the
UVD by ANY means.  This class will include programs which accept a
slightly different set of programs...for example, which allow viruses
to execute while banning virus checkers (whoops!, smells like a virus
to me.)  This is based on the undecidable question of whether two
arbitrary progams accept the same language.

     Now finding a program which, in general, cannot be distinguished
from some other hypothetical program is a theoretical possiblity, but
in practice is impossible.  The problem of finding a program (a virus)
which cannot be excluded by a particular program (your UVD) from a
particular set of programs (all UVD's), is easily solvable. In fact,
it is the problem that Godel solved back before Turing machines were
invented, so the method is independent of things like whether
computers are used.

     Godel proved (constructively remember--he didn't just show it was
possible, he included the recipe) that a universal theorem prover could
not exist, because if it accepted all true theorems (read good
programs) then it was possible to create a false theorem (virus) which
it would also accept.  He also proved that trying to build theorem
provers with restrictions of the form "accepts most true theorems"
(allows most useful programs to run) were a waste of time.  He did
this by showing that any theorem prover that accepted all theorems
which could be proven using only the axioms of Peano arithmetic
would also accept false theorems.  The equivalent for virus checker
programs would be to show not that UVD's that permit spreadsheet
programs to run are flawed, but that a UVD which allows "Hello, World"
to run can be compromised.

     If this still seems esoteric to you, just notice that many
viruses try specifically to hide from virus checkers.  In fact, some
seem to have been created only after studying the code of the existing
virus checkers to figure out how to avoid them.  (It should go without
saying, but... I hope no one will seriously propose that distribution
of virus checker programs should be limited for this reason!)  What
happens then?  The author of the virus checker gets a copy of the
newest virus, and designs a new detector which finds this new virus,
and so on ad infinitum, or until virus authors give up.

     This is the reality.  As long as virus authors exist, even
inadvertent ones, (once upon a time, way back before Robert Morris,
Jr. the ARPAnet was brought to its knees by a bad message created by
line noise...) there will be viruses around.  If computer programs get
smart enough to write their own virus checkers, you will still have
the same problem, you won't be able to tell the good programming
computer programs from the bad ones, just like the current situation
with computer programmers.  Or to put it differently, if it is
possible to create a program which detects ALL viruses, we can use it
to find all potential virus authors.  What nonsense!

     We now return you to your regularly scheduled newsgroup.  Where
hopefully no further proposals of UVD's will appear.  :^)  (I'm not
that much of an optimist.  Some software vendors are STILL using copy
protection schemes, even though every copy protection scheme tells
anyone who studies it how to disable it.  No, I don't pirate
software.  Yes, I do try to boycott any vendor stupid enough to use
them.)

                                        Robert I. Eachus

with STANDARD_DISCLAIMER;
use  STANDARD_DISCLAIMER;
function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...

------------------------------

Date:    08 Feb 90 14:54:00 +0700
From:    [e-mail]
Subject: More general questions about known viruses (PC)

Hi!

I have another three general questions about the known viruses.

(1).  Is there a virus which can infect properly the two hidden DOS
      files (IBMBIO.COM & IBMDOS.COM or their MS-DOS equivalents)?
      Yes, I know that The Dark Avenger, for instance, will infect
      them --- just because they are .COM-files --- but after that the
      system will become non-bootable.  What I mean is --- is there a
      virus which targets these files --- like the Lehigh virus
      targets COMMAND.COM?

(2).  Is there a virus which can infect *properly* overlays?  Again, I
      know that some viruses will infect overlays but the later will
      be damaged.

(3).  Are there viruses which infect .OBJ, .LIB, or .BIN files?  Of
      course, such viruses can be designed, but is this already done?

                                Vesselin

------------------------------

Date:    08 Feb 90 14:56:00 +0700
From:    [e-mail]
Subject: Re: Identification strings

Hi!

In issue #32 Fridrik Skulason writes:

>So - you anti-virus writers out there: Please store identification
>strings encrypted, reversed or somehow modified.

And what if virus-scanning programs are written in such way that they
search the identification string only in the place it has to be ---
not in the whole file?

                        Vesselin

------------------------------

Date:    08 Feb 90 14:55:00 +0700
From:    [e-mail]
Subject: Towards a programmable virus scanner/cleaner

Hi!

Just a few hours ago I got an idea. I think that it's a good one,
that's why I'm pretty sure that I'm not the first one who proposes
this. If it is so (or if the idea is not good enough) just tell me.

We almost already have a programmable virus scanner. If memory serves,
its name is VIRSCAN or something about that. It takes a text file
which contains several entries. Each entry consists of a virus name
(e.g., Jerusalem A), where to search for this virus (e.g., COM EXE)
and a hex string (in ASCII form), unique for this virus. This idea can
be developed further. We can design a high level language for
searching and *clearing* viruses. For example, we can write such
"procedures":

        SearchProc DarkAvenger; /* Search procedure */
                Set VirName 'Dark Avenger';
                OnFound Message '$VirName found in $Media';
                Search For Hex '2E899C53002E8B9CFD062E899C51008C'
                       At Offset -(1800 - 48) From End
                       In (*.COM *.EXE);
        EndProc;
        ClearProc DarkAvenger;
                Move Word From Offset -11 From End
                     To Offset ?? From Beginning;
                        .
                        .
                        .
                Truncate By 1800;
        EndProc;

The operators of the language are obvious:
        ; - ends each operator
        /* comment */
        SearchProc - defines a search procedure.
        ClearProc - defines a clear procedure.
        EndProc - procedure end.
        Set <variable> <string> /* or <number> */ - assigns a string
('Dark Avenger') or a number to a variable.
        Message <string> - outputs a message to the screen. If the
string contains $<variable>, the expected substitution occurs. If you
want to output the '$' character, use '$$'.
        OnFound <operator> - executes <operator> every time the Search
procedure finds a virus.
        Accept <variable> - reads a variable from the keyboard
        Search For <string> At <place-expression>
               In (<specifications>) - searches for the <string> in
the mentioned places. If found, assigns the respective
<specification> to the system variable Media.
        Move <chunk> From <place-expression> To <place-expression>
                - does just what it says.
        Truncate By <number> - truncates file by a given number.
        Unmark <number> - marks DosSector <number> as free in FAT.

Here
        <string> ::= Hex '<hex digits in ASCII form>' :
                     Ascii '<character>*'
        <number> ::= <decimal number> : 0x<hex number>
        <chunk> ::= Byte : Word : <sector>
        <sector> ::= Boot : Partition : DosSector <number> :
                     Sector (<number> <number> <number>)
        <specifications> ::= <file specification>* : <sector>*
        <place-expression> ::= <sector> :
                               Offset <expression> From Beginning :
                               Offset <expression> From End

The interpreter of the language will read the file and execute each
search procedure.  If one of them finds a virus, the respective clear
procedure (if present) will be executed --- unless an option (e.g.,
- -n) is given.

The language described above is much less sofisticated than, say, C
or Pascal. The interpreter may be even a commercial product (hey,
Borland, how about a Turbo Virus Cleaner?) --- it needs not to be
updated with each new virus. Instead the "programs" will be updated
and they can be public domain or can be distributed via e-mail by the
antivirus researchers.

If you are concerned that the virus writers will see how you recognize
their virus (Hi John McAfee!) then you may use some form of
compilation or even encryption by a user-supplied key.

Maybe the above idea is not so good, can be improved, or features have
to be added to the language --- I'm waiting for your opinions.

                        Vesselin

------------------------------

Date:    08 Feb 90 15:43:51 +0000
From:    [e-mail] (Brian Bechtel)
Subject: Re: GateKeeper Aid on AppleShare Server (Mac)

[e-mail] (Roberta Russell) writes:
> I installed Gatekeeper Aid on our AppleShare File and Print Server
> today.

Gatekeeper Aid is designed to prevent infection and spread of the WDEF
virus.  This virus affects the "Desktop" file, which is used by the
Finder to store information about which icons go with which program,
which application to open when you open a document, etc.

AppleShare doesn't use the Desktop file.  Instead, it uses two
invisible files called "Desktop DB" and "Desktop DF" which are kept at
the root of your volume.  You can safely delete the "Desktop" file,
using FEdit, MacSnoop, ResEdit, or similar tools.  Once you do that,
WDEF has no home, and no way to propogate from such a server.
GateKeeper Aid then becomes superfluous on the server machine (only.)

The message "GateKeeper Aid encountered FCB expansion" probably means
that GateKeeper Aid noticed that AppleShare expands the number of File
Control Blocks so that more files may be open on an AppleShare server
than would be allowed on a user machine.

Disclaimer: I'm just another grunt.  I haven't been actively fighting
viruses, so don't take this message as Word From On High.

- --Brian Bechtel     [e-mail]     "My opinion, not Apple's"

------------------------------

Date:    Thu, 08 Feb 90 10:30:00 -0600
From:    Meesh <[e-mail]>
Subject: WDEF & rebuilding the desktop (MAC)

This may sound like a dumb question, but if WDEF infects the desktop,
why don't you just hold down the option-command keys and rebuild your
desktop the next time you reboot?   Wouldn't that bump WDEF out of
your system?  Obviously, I wouldn't know, we haven't been infected by
it.

If you're running under Finder, you can rebuild your desktop while
you're quitting from an application.

michelle g.
computing information services

------------------------------

Date:    Thu, 08 Feb 90 10:45:00 -0400
From:    Michael Greve <[e-mail]>
Subject: My Jerusalem B nightmare! (PC)

  I want to thank all the people who sent me messages on using the
CLEAN program.  Unfortunately the program did not work.  It removed
the virus and shrank the .exe file from 260,000+ bytes to 84,000.
Needless to say this file didn't run.  Does anybody have any other
ways of getting rid of this virus.  Is the Jerusalem virus a
particularly difficult virus to get rid of???  Are PC viruses
generally nastier and more difficult to get rid of than PC viruses??
We have 3 PC labs here at Wharton and haven't had any viruses hit
them.  I we have one small MAC lab that has seen nearly every virus
imaginable.  Nearly every student's MAC disk has some kind of virus.
I guess what I'm asking is with all the PC viruses around why aren't
more machines infected.  ARe PC viruses harder to catch and harder to
get rid of?

  In the early days of viruses 1986-1987 we had a couple disks that
had what was called a C-BRAIN virus.  From what I remember all it did
was change the volume name of your PC disk to C-BRAIN.  I think there
was a similar one called ASHUR.  Were these really viruses??  Did they
do any real damage?  They seem tame compared to today's viruses.  I
remember everyone in my office panicking when a C-BRAIN showed up on a
students disk.  We had meetings, planned strategy, issued fliers to
the whole school.  Seems kind of silly if this virus did no damage.

   Thanks for any assistance.

                                        Michael Greve
                                        University of Pa.
                                        Wharton Computing
                                        [e-mail]

------------------------------

Date:    Thu, 08 Feb 90 15:57:30 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Gates of Hades ? (PC)

I just received a (unconfirmed) virus report - has anyone heard of
a virus called "Gates of Hades" ?

It is reported to be able to do physical damage to hard disks.

Fridrik Skulason   -   University of Iceland, Computing Services.
[e-mail]        Technical Editor, Virus Bulletin.

------------------------------

Date:    Thu, 08 Feb 90 15:59:06 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Virus insurance offered

The Allstate Insurance Co. is now said to offer virus insurance. Its
home and business insurance policies are also said to have been
extended to cover virus damage to PCs.

Can anybody provide more details on what the fine print looks like ? :-)

"...virus damage to PCs" sounds like insurance against viruses that make
a computer go ***BOOOOOOMMMMM*** or turn into molten metal. :-)  Do they
also cover damage to data and lost work ?

Fridrik Skulason   -   University of Iceland, Computing Services.
[e-mail]        Technical Editor, Virus Bulletin.

------------------------------

Date:    Thu, 08 Feb 90 16:00:31 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Novell network virus ??? (PC)

Can anyone confirm a report that a virus designed to attack Novell
networks exists ?

This "virus" is said to scrabmle FAT information on the server, making
all files there useless.

It is quite possible that this "virus" does not exist, or that the
original report was incorrect - maybe they just got attacked by a
trojan (or a disk failure).

Fridrik Skulason   -   University of Iceland, Computing Services.
[e-mail]        Technical Editor, Virus Bulletin.

------------------------------

Date:    Thu, 08 Feb 90 13:09:57 +0600
From:    G7AHN <[e-mail]>
Subject: Re: More about 847 (PC)

 This virus has been around for years. It was published in the April
1987 edition of PIXEL magazine, as an example of virus program and 3
months later the 'antibiotic' was published in the same magazine. They
said that they delayed the release of the disinfector so that readers
could set up a few practical jokes. I have the assembler source code
with the original comments and the BASIC program.  I got them from a
friend of the author of the virus. The author is a well known computer
wizard in Greece, known as Nick the Greek...

Costas Krallis
Imperial College
London, UK

E-Mail: [e-mail]
        ukc!iccc!g7ahn

------------------------------

Date:    Thu, 08 Feb 90 10:12:00 -0400
From:    "SCOTT D. GREGORY" <[e-mail]>
Subject: F-PROT Question (PC)

An open question to frisk and the VIRUS list -

I have been using F-PROT as an installable device to check viruses since I
downloaded it off SIMTEL (A while ago).  My question concerns its
actions/methods.  I understand basically how SCANRES works as a TSR by
trapping interrups, does F-PROT work in a similar way?  It seems such a
small program when installed (1.5k), I assume it does what it is supposed
to; though I hope it never needs to tell me that I'm loading a virus.

                                                Scott G.
                                                [e-mail]

P.S.  The docs say that it is supposed to notify of its installation - mine
doesn't, but shows up on a device driver list (TSR 2.9 Utilities), is it
working?

- - Opinions Bought and Sold - Really Cheap - Polititians Welcome

------------------------------

Date:    08 Feb 90 17:56:41 +0000
From:    [e-mail] (Edward A Wahl)
Subject: Disinfectant 1.6 (Mac)

     YES! There is a disinfectant 1.6.  It is a quick release before version 2
is released to the public.  It has a new algorithim that scans for a general
virus of the nVira and nVirb strains.  This does NOT protect against the NEW
trojan designed to go off on 2/10/90!  But it is a powerful tool.  If anyone
gets a copy and finds the new nVIR strains, please let me know.

- ------------------------------------------------------------------------------
only a mediocre man is always at his best    -W Somerset Maugham

It's better to be silent and thought a fool than speak and remove all doubt.
                                                      -Abraham Lincoln
[e-mail]    [e-mail]
     Ed Wahl   CIS/ENG  "What opinion, I'm brainwashed?!"

- ------------------------------------------------------------------------------

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Friday,  9 Feb 1990    Volume 3 : Issue 36

Today's Topics:

WDEF at James Madison University (Mac)
F-PROT for the PC: Is it any good?
RE: Copyrighting virus code
Re: Mac Virus Harmlessness
Re: Idea for WDEF Innoculation (Mac)
Re: Disinfectant 1.6 (Mac)
WDEF A hit, report & discussion (Mac)
Info on Stoned/Marijuana virus
Re: Mac Virus Harmlessness
Virus Bulletin

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

---------------------------------------------------------------------------

Date:    Thu, 08 Feb 90 13:45:00 -0500
From:    <[e-mail]>
Subject: WDEF at James Madison University (Mac)

Hello to all!

For those tracking WDEF, it has made it to the Shenandoah Valley. Here
at JMU, we have found WDEF in all of our Mac labs and quite a few of
the administrative offices that have Macs. Currently, we are using
Virex 2.3 and Disinfectant 1.5 to remove infections as they are found.
We are concerned about reinfections, however, and would appreciate any
and all suggestions.

Also, would someone please clear up the confusion about Disinfectant
1.6?

[Ed. See message below.]

Thanx,

John Bowers
Academic Computing Services
James Madison University
Bitnet: ACS_JOHN@JMUVAX1

------------------------------

Date:    08 Feb 90 20:19:39 +0000
From:    [e-mail] (Ron Warren Evans)
Subject: F-PROT for the PC: Is it any good?

I'm a user consultant at Brandeis University. Somehow the
responsibility for learning about and killing viruses for both the Mac
and the PC has fallen to me.  I am in the process of making a
recommendation for antiviral packages for the PC.  For a while it
seemed that there was no package that provided really adequate
protection: Flu_Shot+ would only protect against infection, but could
not identify an attacking virus or disinfect a disk, and Viruscan
could only identify viruses, not protect against them or disinfect.

Recently, though, I downloaded a package from Simtel20 called F-PROT.
If the documentation is to be believed, it protects against and
identifies viruses and disinfects disks as well.  Moreover, it is
cheaper than either of the other packages.  I would like to recommend
this package to my supervisor, since if F-PROT works, it will make my
job a lot easier.  My supervisor, however, is suspicious.  He points
out that F-PROT is virtually unknown in the U.S., is produced by a
lone Icelandic programmer, is untested here, and may not be
well-supported.

My request: would any of you Netlanders who have used F-PROT for a
while let me know how well it works in your experience and if you have
had any problems with customer support, bugs in the program, ease of
use, and so on?

Please email me your responses and I will post a summary to the Net.

[Ed. I'd be willing to bet that there's at least one "lone Icelandic
programmer" on this list that would be willing to help you out.  :-)
Still, an objective (read: independent) review of F-PROT and other
products would be very appreciated.  It's been a long time since we've
seen such a thing here.  Any takers?]

- -----------------------------------------------------------
I don't want to die!  Existence is one of my strong points!
Ron Warren Evans... [e-mail], [e-mail]
U.S. Snail: 139 Salem St. #6, Boston, MA 02113

------------------------------

Date:    Thu, 08 Feb 90 16:30:00 +0000
From:    "Olivier Crepin-Leblond" <[e-mail]>
Subject: RE: Copyrighting virus code

In VIRUS-L V3-34 Steven C Woronick <[e-mail]> writes:

>Even if you could copyright viral code, it's
>not likely to discourage the kind of people who write viruses (aren't
>those the ones you are really after?) from copying it.  Also, what
>happens if some virus-loving person copyrights it before you do and
>then grants universal privilege to copy?  Just wondering...

My idea was not to discourage hackers (or whatever name you give them)
to write viruses. Thieves steal even though it is illegal ! The idea
was to discourage computer users, students, etc. to hold copies of
viruses.  In December of last year, I went to a computer fair here in
London.  The machines concerned were PC compatibles. In one corner of
the place (near the... bar) hackers were exchanging code, etc. It is
perfectly illegal and I am sure the organisers of the exhibition were
not aware of the events.  I discovered it while waiting to get a drink
(it's called eavesdropping).  It seems that virus source code is
highly sought after by these people, aged 17 -> 30.

I can hardly imagine some individual copyrighting virus source code.
Anyone doing that will probably be in for a lot of trouble...

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|Olivier M.J. Crepin-Leblond, Comp. Sys. & Elec. Eng    | On this computer,   |
|Electrical & Electronic Eng, King's College London, UK | a flame-proof       |
|BITNET  : <zdee699%elm.cc.kcl.ac.uk@ukacrl>            |  shield, is an      |
|INTERNET: <[e-mail]>| expensive gadget... |
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

------------------------------

Date:    08 Feb 90 20:59:34 +0000
From:    [e-mail] (David Vronay)
Subject: Re: Mac Virus Harmlessness

[Joe McMahon] writes:
>It's interesting, but up until now, most viruses on the Mac have been
>"damageless" - the only reason the cause trouble is because of bugs
>and incompatabilities, not deliberately harmful code. nVIR, at worst,
>causes your Mac to beep in some cases (side effects are worse -
>crashes, hangs, printing failures).
>
>Perhaps we just haven't had the right (wrong?) people writing Mac
>viruses so far. Any ideas?

(I am the last person who would want to add to virus paranoia, but..)

  More sobering is the possibility that there are viruses sitting
dormant on our machines as we speak that are bug-free and thus-far
undetected.  Take WDEF, for instance.  Consider a scenario in which
the programmer had actually followed the compatability guidelines and
produced error-free code.  It would probably be quite a while before
any of us had noticed this little "addition" to our desktop files.  (I
don't know about everyone else, but I don't exactly check my desktop
file for new resources every day)

  When you consider that a) the reason we know about most of the
viruses that are around today are due to stupid programming errors,
and b) to date very few viruses have been manevolent, and c) to date
most viruses have not been clever at all about how they replicate
(WDEF, for example, could have patched itself into an _EXISTING_ WDEF
resource, so that the infected WDEF would still perform normal, as
well as viral, activity) one can only conclude that we are at the tip
of the virus iceberg.  The problem could get _much_ worse.

- -ice
================================
reply to:  [e-mail]    AppleLink:  ICEMAN
disclaimer:  (not (apples-opinion-p (opinions 'ice))) => T
================================

------------------------------

Date:    08 Feb 90 21:30:07 +0000
From:    bgsuvax![e-mail] (William C. DenBesten)
Subject: Re: Idea for WDEF Innoculation (Mac)

[e-mail] (Jason Ari Goldstein) writes:
> Just like everywhere else the WDEF is thriving here at Carnegie-Mellon
> Univ.  I recently removed WDEF A & B off of 15 disks of a friend of
> mine.  When I commented to somone here about the virus they said there
> was nothing they could do to stop it, except remove it once a machine
> got infected.

Install Gatekeeper Aid 1.0.1.  It will check a disk as it is inserted
and remove the offending WDEF resource.  It is an init that you stick
in your system folder.  It is available from most archive sources or
your favorite software collector.

> ...

> The only problem with this is that it is a virus also, but with the
> proper prompts (allowing the user the choice of being innoculated) I
> don't think this would be a problem.  I know I would mind not ever
> being infected by a virus that kills other viruses.

I most certianly do mind being infected by a virus.  I don't care what
it does or does not do.

In theory, WDEF does not do anything destructive.  In reality, WDEF
causes wierd errors.  Fonts misbehave and I blame it on Quickmail
crashing.  These are because of bugs in the virus code itself.

The fact that I drag something to my system folder is me giving it
permission to be executed in the future.  I would much rather install
something this way than have it copy itself lord-knows-where.  There
are additional problems.  If there is a bug, it may not be obvious how
to remove the virus.

There is also the issue of updates.  If it is automatically copied,
you will get a large body of people using it, but not knowing or
caring about making sure that they have the latest version.

- --
William C. DenBesten   is   [e-mail]  or   [e-mail]

------------------------------

Date:    Thu, 08 Feb 90 16:02:27 -0500
From:    "Robert Del Favero Jr." <clunker![e-mail]>
Subject: Re: Disinfectant 1.6 (Mac)

>     I have recently read something about Disinfectant 1.6 from this
>newsgroup.  Its author said that there was no Disinfectant 1.6 and it
>maigt cause potential porblems on virus detection.  Someone in our lab
>downloaded it and has been using it without any obvious trouble.  I
>would appreciate any further comments on this application.  So, again,
>is there any upgraded version of Disinfectant after version 1.5 ?  If
>not, is there any more information about this "fake" Disinfectant ?

Here's the story.  A few weeks ago, when the latest version of
Disinfectant was 1.5, someone made a typo in a posting to comp.sys.mac
referring to Disinfectant 1.6.  The author of Disinfectant quickly
pointed out that there was no 1.6 yet, and that if you saw a 1.6 *at
that time* then it was a fake.  Then, about a week ago, the author
released a *real* 1.6 version with some new features.  So, if your
friend downloaded his copy of version 1.6 in the last week or so, it
is probably legitimate.

 -------------------------------------------------------------------------
Robert V. Del Favero, Jr.            ISC-Bunker Ramo, an Olivetti Company
[e-mail]                     Shelton, Connecticut, USA
OR clunker![e-mail]

------------------------------

Date:    Thu, 08 Feb 90 11:18:59 -0600
From:    "McMahon,Brian D" <[e-mail]>
Subject: WDEF A hit, report & discussion (Mac)

I suppose it was only a matter of time, but I can still appreciate the
irony ... after posting a question about reporting and tracking
infections about a month ago, I'm now in the position of reporting one
myself.

1) DISCOVERY: "WDEF A" was found in several Macs at Grinnell College
this past Tuesday, the 6th of February.  The initial discovery came
when a faculty member reported strange behavior on his machine,
including "Application unexpectedly quit" under MultiFinder, usually
associated with insufficient available memory. Disinfectant 1.5
spotted the infection.  Besides machines in the faculty offices, the
building in question also contains a secretaries' office, with a few
machines used for service requests, etc. This common area was also
infected, meaning that any faculty who had used the area or sent
diskettes down were also hit.

2) INITIAL RESPONSE: Our first priority was to contain the outbreak
and to install protective software (see below).  Our Mac support staff
(both of us! :-) made the rounds of faculty in the building.  At each
station, we would run Disinfectant to check the machines, and if WDEF
was found, kill it by rebuilding the desktop file.  No matter whether
we found anything or now, we would install anti-viral software as we
went along.  We kept a running list of other potential victims, and
wound up checking most machines on campus.  Besides the faculty area,
we found one isolated case in an administrative office (they
frequently send disks to service bureaus), and to our embarassment,
the public-signup station in the computer center itself.

3) FOLLOW-UP: Much to our relief, the infection appeared to be
contained to the one faculty area and the two other machines.  In
particular, we were fortunate that it had not spread to faculty areas
in other buildings or to the student lab.  The public station in our
office, which is used heavily for page layout and printing, posed more
of a problem.  However, we did have a signup log of users, and are
contacting them individually.  Our next step was user education.  We
drafted an article for on-line news and the newsletter, stressing the
counter-measures available.  We also placed copies of the anti-virus
tools on the public Mac, and posted a condensed version of the
newsletter article nearby.

4) TOOLS USED: For detection, we used Disinfectant 1.5.  (1.6 arrived
late the same day from SCFVM -- of course!)  Removing WDEF was
accomplished by rebuilding the desktop, and at the same time we
installed GateKeeper 1.1.1 and GateKeeper Aid 1.0.1 to protect against
future infections.

5) LESSONS LEARNED: Up until now, we had been very lucky at Grinnell.
Instances of infection were almost non-existent.  Although the level
of virus awareness among the staff was fairly high, we'd been lulled
into a sense of complacency.  Specifically, we did not aggressively
push the updates to existing tools that would have caught WDEF.  In
several cases, infected machines were running older versions of virus
blockers, which the WDEF virus evades.  We're now working on a way to
get updates to the users promptly as they come out.

6) TRACKING WDEF: I've noticed a flurry of WDEF reports lately,
including several from Midwestern sites, and (as mentioned) tracking
the spread of a new virus or strain intrigues me.  Wild speculation
follows: Students who live in areas already infested by a new virus,
but go to college elsewhere, also new or returning faculty, would make
an excellent vector to spread the new critter nationwide.  One
conclusion is that the start of a new semester or term is a time for
increased vigilance.  Another would be that WDEF is now all over the
place.  *sigh* Personally, I suspect that our infection actually
involved at least two sources, there being no plausible path between
the faculty area and the admin office.  Most likely, the one came from
a user introducing it to the central secretarial area, the other from
a service bureau.

Usual and customary disclaimer, my opinions only ... (mumble).

Brian McMahon  <[e-mail]>
Grinnell College, Iowa

------------------------------

Date:    Thu, 08 Feb 90 22:21:02 -0500
From:    Peter Jones <[e-mail]>
Subject: Info on Stoned/Marijuana virus

We suspect an outbreak of the Stoned/Marijuana virus at UQAM. Is there
any information available on what damage this beast does, and how it
propagates?  What tools are available to combat it? CLEANP57 & co from
John McAfee claim to be one possiblity.

Peter Jones     MAINT@UQAM     (514)-987-3542
"Life's too short to try and fill up every minute of it" :-)

------------------------------

Date:    08 Feb 90 23:06:50 +0000
From:    Matthias Urlichs <[e-mail]>
Subject: Re: Mac Virus Harmlessness

In comp.virus, [e-mail] (Joe McMahon) writes:
< It's interesting, but up until now, most viruses on the Mac have been
< "damageless" - the only reason the cause trouble is because of bugs
< and incompatabilities, not deliberately harmful code. nVIR, at worst,
< causes your Mac to beep in some cases (side effects are worse -
< crashes, hangs, printing failures).

nVIR, in its very first incarnation, didn't beep. It took a random
file in your System folder, and deleted it. Not good.

When I found it on my Mac, I tried to alert people about this.  That
proved to be difficult. Someone at Apple Germany stated that due to
the nature of the Mac's resource structure, virii are impossible on
the Mac. (Ha!)  I also didn't have any kind of AppleLink or Usenet
access.

The only way out, in my (at that time) unexperienced opinion, was to
disassemble the beast and rewrite it so that it (a) superseded other
versions of itself, (b) beeped instead of deleting files, and (c)
announced itself.  Change (c) seems to have got lost on its way --
nVIR has a habit of partial replacement. Testing was difficult because
of general nonresponsiveness on the part of anybody I told about the
virus, and of course because I feared that the original would spread
too far.

Please, no flames about my lack of common sense, sense of
responsibility, or whatever. I know that already; what's more, it was
some years ago and I seem to have grown up since then.  Growing up,
BTW, is something I would strongly recommend to any other virus
"author" who seem to get a kick out of seeing their intruding code
(crash) on as many Macs as possible.

However, my nVIR version seems to have succeeded in destroying the
older strain. At that time, there didn't seem to be any way to
convince people about the virus threat except by example, and random
beeps are somewhat more benign than silently thrashing files...  Since
all other virii on the Mac are "benign" in the sense that they don't
deliberately destroy files, I guess it could have been worse.

- --
Matthias Urlichs

------------------------------

Date:    Fri, 09 Feb 90 12:36:59 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Virus Bulletin

I mentioned the Virus Bulletin in a recent article, and as a result I
have received a number of enquiries. The following note should answer
the questions....

- ----------------------------------------------------------------------------

The Virus Bulletin is published monthly - average length maybe 16
pages or so.  It contains detailed dissections of viruses, reviews of
anti virus software, virus-related articles, hexadecimal search
patterns etc.

Contents of the February issue:

        Editorial
        Virus Reports
        Guidelines for Virus Prevention & Post-Attack Recovery
        IBM PC virus patterns
        Dissection: Dark Avenger
        High-Level Programs & the AIDS Trojan
        Evaluation: Virex 2.3
        Macintosh software list
        Evaluation: Iris Anti-Virus Software
        News

The editor (Edward Wilding) does not have access to the net yet.

The list of editorial advisors is impressive:

        Jim Bates, Bates Associates, UK
        Dr. Fred Cohen, Advanced Software Protection, USA
        Phil Crewe, Fingerprint, UK
        Dr. Jon David, USA
        David Ferbrache, Heriot-Watt University, UK
        Dr. Bertil Fortrie, Data Encryption Technologies, Holland
        Hans Gliss, Datenschutz Berater, West Germany
        Ross M. Greenberg, Software Concepts Design, USA
        Dr. Harold Joseph Highland, Compulit Microcomputer Security
          Evaluation Laboratory, USA
        Dr. Jan Hruska, Sophos, UK
        Dr. Keith Jackson, Walsham Contracts, UK
        Owen Keane, Barrister, UK
        Yisrael Radai, Hebrew University, Israel
        John Laws, RSRE, UK
        David T. Lindsay, Digital Equipment Corporation, UK
        Martin Samociuk, Network Security Management, UK
        John Sherwood, Computer Security Consultants, UK
        Roger Usher, Coopers & Lybrand, UK
        Dr. Ken Wong, BIS Applied Systems, UK

Subscription is restricted - only companies, universities and qualified
individuals. Price: US$ 350/year or UK pounds 195/year

Subscription enquiries:

        Virus Bulletin Ltd,
        Haddenham
        Aylesbury
        HP17 8JD
        England

US subscriptions:

        June Jordan
        Virus Bulletin
        P.O.BOX 875
        454 Main Street
        Ridgefield CT 06877
        USA

- -------------------------------------------------------------------------
Fridrik Skulason   -   University of Iceland, Computing Services.
[e-mail]        Technical Editor, Virus Bulletin.

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Monday, 12 Feb 1990    Volume 3 : Issue 37

Today's Topics:

Appleshare Servers and WDEF
Re: Are virus sources public domain software ?
Re: WDEF and AppleShare (Mac)
Universal virus detector / Biological analogy
Which checksum algorithm?
The Executable Bit
Re: Disinfectant 1.6 (Mac)
Re: More about WDEF (Mac)
WDEF report from Detroit (Mac)
Re: More about WDEF (Mac)
Re: programmable virus scanner
Re universal detectors.

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

---------------------------------------------------------------------------

Date:    Fri, 09 Feb 90 08:58:35 -0500
From:    Joe McMahon
Subject: Appleshare Servers and WDEF

Hah! Another good defense for your hard disk. I believe there's an
INIT available which adds the Appleshare desktop management code to
your Mac (if I remember right, the "Oscar" program includes this).
Install that on your hard disk in the System folder, blow away the old
Desktop file with ResEdit/Disktop/et al, and there you are. As Brian
puts it, there's nowhere for WDEF to live. Does Apple support using
the Desktop Manager INIT on a non-Appleshare Mac?

 --- Joe M.

------------------------------

Date:    09 Feb 90 13:48:13 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Re: Are virus sources public domain software ?

[e-mail] writes:
>Well, how about some reliable organisation (the CERT, for example)
>registering the source code under copyright laws ?

There are numerous reasons why this would not work - the most simple
one is that the original author holds the copyright, even if there is
no "Copyright (c) 19xx, xxxxxxxxxx" message visible.

- --
Fridrik Skulason   -   University of Iceland, Computing Services.
[e-mail]        Technical Editor, Virus Bulletin.

------------------------------

Date:    Fri, 09 Feb 90 08:50:00 -0500
From:    Peter W. Day <[e-mail]>
Subject: Re: WDEF and AppleShare (Mac)

Re the discussion of infection of AppleShare servers by WDEF and
whether to run GateKeeper there, and Brian Bechtel's point that the
server does not use its desktop file, so the disktop file can be
removed, after which the server can not be infected by WDEF.

Even if you leave the file "desktop" on the server, that file is not
seen by clients (even using programs that can see the desktop file on
local disks), so it appears that there is no way a client can infect
an AppleShare server with WDEF.  Clearly you could do so by putting an
infected diskette in the server when it was running as a workstation
(e.g. by booting it using an infected diskette).  But could you infect
the server by inserting an infected diskette in it while it was
running as a server? Once infected, will the server infect local disks
of clients?

------------------------------

Date:    Fri, 09 Feb 90 16:08:24 +0000
From:    "Dr. A. Wood" <[e-mail]>
Subject: Universal virus detector / Biological analogy

There has been much rhubarbiage about the possibility of writing a
program which will detect <all> viruses in incoming programs, not only
a set list of viruses that it has been told about. I suspect that this
is partly motivated by trying to achieve the efficiency of biological
immune systems - there have been a few 'biological analogy' articles
in Virus-L before. This analogy will not work - biological immune
systems are set up in a different way.

Long before birth, all possible antibody-producing cell types appear
in the body.  As in the womb before birth in the normal case, no
foreign matter can get in, everything in the fetus is native and
belongs. And, at that stage, every antibody-producing cell that loses
its antibody, dies, for it must have lost its antibody by an
auto-immume reaction. Thus all auto-immune antibody-producing cell
lines are eliminated.  Time passes and the baby is born.  Then, any
antibody-producing cell that loses its antibody must have lost it to
some foreign matter. So it multiplies, and its descendants produce
much antibody to combat the invader. After birth, nothing else gets
unopposed into the body.

The only way to imitate this in computers is to have an immune program
which knows every program which will be run on that computer, and
rejects all strange programs. No good! So, is there any point in this
email-space-wasting discussion continuing? Bodies have a permitted
list and exclude all others; computers have a forbidden list and admit
all others. To a computer, a new virus is merely a new program, and
some human has to find that it is harmful and then add it to the
forbidden list.

Also, any two bodies' cells (except identical twins) have different
immunotypes, and attempted grafting fails, thus any bacterium that
learns to masquerade as a legal cell of body A, is rejected on trying
to invade body B. The computer analogy of this would be for each
individual microcomputer's copy of each authorized program to be
different.

The only thing that I can suggest is for microcomputer designers to
start using the mainframe technique of preventing programs running
under ordinary mode from writing to system areas, and for only the
suppliers of the computer to be allowed to write system programs which
run under everything-permitted mode. That will exclude damaging
viruses, but will still allow the sort of virus that merely multiplies
and wastes time and storage space.

{A.Appleyard} (email: [e-mail]), Fri, 09 Feb 90 15:38:12 GMT

------------------------------

Date:    Fri, 09 Feb 90 11:54:00 -0500
From:    [e-mail]
Subject: Which checksum algorithm?

>To make the question a little more specific, of the checksum routines
>available today, which would you select.

This is slightly a less, rather than more, specific question.  Your
original question suggested that strength would be the basis of my
choice.  In fact, crypto theory teaches that knowledge of strength is
very expensive.  I would prefer to make my selection based upon
knowledge that comes a little cheaper.

The answer will be influenced by application and environment.  However,
in general:

If I were an employee of the U. S. Government, I would choose the DES.
It is available and the authorities have told me that it is strong
enough for their purposes.

In other cases, I would choose from among CRC, DES, and RSA.  We know
their strength with sufficient confidence, it is sufficient for most
applications, and they are available.

In the absence of more knowledge about the application and environment,
deeper analysis is not warranted.

William Hugh Murray, Fellow, Information System Security, Ernst & Young
2000 National City Center Cleveland, Ohio 44114
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840

------------------------------

Date:    Fri, 09 Feb 90 12:26:00 -0500
From:    [e-mail]
Subject: The Executable Bit

The data object marked with an "executable bit"  that Jerry L. and Dave
Chess are discussing is an example of a "strongly typed data object."
A "typed" data object is one upon which only a limited set of operations
are valid.  A "strongly typed" object is one in which the rules for the
type are known to and enforced by the environment.  In this case, for
environment, you may substitute hardware.

The IBM AS400, with which people in Yorktown, if not Poughkeepsie,
should be familiar, implements such strongly typed objects.  In this
system it is not normal for something to be both executable and
modifiable at one and the same time.  As a rule, programs can never be
modified.  They can be replaced, but not changed.
That is to say, the name of a program is unique; if you replace it, it
automatically receives a new unique name.

This meets Jerry's requirements, if not his objectives.  While changes
to programs will be hard to conceal, for reasons of useability, progams
are invoked by their short names.  A person might have to note the
change for protection to result.  And of course, it might be possible to
create a new environment on top of the one provided by the system, and
not visible to it, which would execute modifiable objects.   A REXX
interpreter of Hypercard interpreter, for example, could be so
implemented.

However, in response to Dave's question about whether such objects would
"get the bit", it is also possible to do it the other way.  Scripts for
the AS400 command language (named CLs in the Poughkeepsie style) are
typed objects.  I hope that REXX scripts, for that SAA interpreter,
when it becomse available for AS400, will be typed objects.  (Will
Rochester prevail over Poughkeepsie; will fair Harvard conquer Princeton
at last;  or has von Neumann vanquished Aiken forever?  Watch this
space.)

William Hugh Murray, Fellow, Information System Security, Ernst & Young
2000 National City Center Cleveland, Ohio 44114
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840

------------------------------

Date:    Fri, 09 Feb 90 14:28:00 -0600
From:    John Norstad <[e-mail]>
Subject: Re: Disinfectant 1.6 (Mac)

[e-mail](Fung P Lau) writes:
>      I have recently read something about Disinfectant 1.6 from this
> newsgroup.  Its author said that there was no Disinfectant 1.6 and it
> maigt cause potential porblems on virus detection.  Someone in our lab
> downloaded it and has been using it without any obvious trouble.  I
> would appreciate any further comments on this application.  So, again,
> is there any upgraded version of Disinfectant after version 1.5 ?  If
> not, is there any more information about this "fake" Disinfectant ?

Disinfectant 1.6 is a bonafide new release. There was some confusion on
the UseNet newgroup comp.sys.mac before 1.6 came out about a possibly
"bogus" version 1.6, but nothing ever came of that confusion.

Version 1.6 contains important new generic nVIR  clone detection and
repair code.  All Disinfectant users should upgrade to the new version.

(I am the author of Disinfectant)

John Norstad
Northwestern University
[e-mail]

------------------------------

Date:    Fri, 09 Feb 90 14:37:16 -0600
From:    John Norstad <[e-mail]>
Subject: Re: More about WDEF (Mac)

[e-mail] (Wing Leung) writes:
> Can someone tell me is WDEF an illegal string in the resource code?
> How about the program called WDEF uploaded in comp.binaries.mac?
> In fact, I've found some WDEF resource code in system version 6.0.3.
>         Please tell me more about this resource code.

WDEF resources are a normal part of the Mac operating system.  You
should only be concerned if you find a WDEF resource in a Finder
Desktop file.

John Norstad
Northwestern University
[e-mail]

------------------------------

Date:    Fri, 09 Feb 90 16:13:30 -0500
From:    "Dennis P. Moynihan" <[e-mail]>
Subject: WDEF report from Detroit (Mac)

Yup, Wayne State in Detroit got hit about Feb 3.  The embarrasing
thing is that we found it on one of the Computing Center's servers
(where all our anti-viral people work) and on, um, my machine.  Sigh.
We're putting a notice out to the rest of the campus and we'll see if
the hills are alive with WDEFs....

- --------------------------------------
Dennis Moynihan    (DMOYNIHA@WAYNEST1)
Computing and Information Technology
Wayne State University
Detroit, MI

------------------------------

Date:    09 Feb 90 18:38:40 +0000
From:    "David N. Schlesinger" <[e-mail]>
Subject: Re: More about WDEF (Mac)

[e-mail] (Wing Leung) writes:
> I've found some WDEF resource code in system version 6.0.3.  Please tell me
> more about this resource code.

WDEF is, in fact, the signature of a standard resource type: the
"W"indow "DEF"inition porcedure resource.  The WDEF _virus_ is
distinguished by being a resource of type WDEF in the invisible file
"Desktop" in the root directory of a volume.

Hope this helps...

Lefty

===========================================================================
          David N. Schlesinger   || "There's a word for it: words don't
          The Wollongong Group   ||  mean a thing.  There's a name for it;
Internet: [e-mail]          ||  names make all the difference in the
POTS:     415/962-7219           ||  world..." -- David Byrne
===========================================================================

------------------------------

Date:    Fri, 09 Feb 90 14:42:18 +0000
From:    "David.J.Ferbrache" <[e-mail]>
Subject: Re: programmable virus scanner

Yes, the idea is an excellent one. The concept of a programmable virus
recognition system has already been adopted on the Mac, specifically in
release 3.0 and later of Jeff Shulman's virus detective package. This
desk accessory uses an abstract definition language for the detection
of viruses by resource patterns or code signatures.

Jeff's patterns allow quite complex expressions and sub expressions tied
with the cand operator (&). The product can test for the creator and
type of any file; the resource type, name and size; and a code string
to be searched which can be offset by a fixed value from the start or
beginning of the resource.

Jeff allows wildcarding in a limited form to occur in his search
strings. This takes the form of a skip over non-significant bytes, thus
the search string "3C#500" would match 3C, skip 5 bytes and then match
00. Thus matching the string 3C12C9006A800.

This adaptability has proved virus detective to be one of the most
useful anti-virus utilities on the Mac. Thus a new virus (such as the
WDEF strain) can be reported along with a virus detective
identification string which can be rapidly added by the user to his
virus detective copy.

Finally virus detective incorporates generic detection patterns for
most Mac viruses, thus eliminating the problem caused by the regiment
of nVIR virus clones (most of which are produced by a simple binary or
resource edit of the infected file).

Obviously the general virus detection system may be less efficient
than the alternative specialist detection software, however the use of
precise offsets may cause significant improvements in pattern
scanning. Other extensions could include test expressions for the file
alteration date and length information in the directory (catching the
648 seconds signature and the Oropax rounded file size signature); and
extended wildcard matching to deal with the 1260 decryptor scrambling
routine. (With a possible syntax allowing ?X to match up four random
characters before a further match, we could have
?20B8#4?20B9#4?20BF#4?20310D?203105?2047?2040?20E2 this rather complex
pattern would allow for up to 32 random bytes to be inserted between
each significant byte in the 1260 decryptor string and would also skip
the variable values in the MOV instructions.  Naturally as the form of
the expression becomes more complex (ending in full regular
expressions with exponential search time and memory requirements)
search times will increase.

In summary the requirements for filter expressions are:

1. Directory entry filters - file length (including modular value test, eg
    MOD 51), file alteration date, attribute settings and file extensions
2. File characteristic filters - possibly including the destination of the
   initial jump instruction, definitely including a form of code scanning
   using wildcarded expressions (either in a specified scan range or at
   a number of scan ranges based on offset from the start and end of the
   file).

Naturally such a virus detector could be extended to allow scan of
memory or of a range of disk sectors, thus allowing one program to
deal with application, boot sector and partition record viruses. (In a
similar manner to the way norton utilities allows for a variety of
data sources - sector, file, cluster etc).

Anyway just a few thoughts.

------------------------------

Date:    Fri, 09 Feb 90 23:39:54 -0400
From:    GEORGE SVETLICHNY <[e-mail]>
Subject: Re universal detectors.

Enough has been said on this list to convince most people that a
universal virus detector (UVD) is impossible, and I've given my own two
cent's worth in favor of this position. If by "virus" we mean to
include a whole range of "nasty" programs, then one also runs into
problems of correctness of code and bugs, and gets tangled up in
questions of human intent, which makes the discussion, though still
mathematically viable, (given sufficient abstraction) rather trivial in
the end. The answer is that no UVD exists.

Even defining viruses as some types (not all) of "self-duplicating
codes" and leaving trojans and other nasties aside will not improve the
situation much, as one still faces quite general undecidability
theorems. As I have tried to point out, almost any question about a
program's performance is undecidable.

In Virus-L v3, issue20 [e-mail] (Russell McFatter) argues that
one should not try to determine what a program *will* do but what it
*might* do and just not run those that might infect others. In
principle this sounds like a good idea, since a-priori such a
rephrasing of the problem could make it decidable. What makes it
totally unviable is the present hardware (at least on PC-type machines,
I'm not that familiar with Macs) as I tried to point out in Virus-L v3
issue22.

Now there just _*MAY*_ (note the triple enphasis) be a theorem of the
following type:

        I. Given such-and-such memory and microprocessor architecture,
        then any program containing a virus (however that is defined)
        will necessarily have a certain patern P in the object code.
        II. Any program that does not contain a virus can be written in
        a way that does not lead to pattern P in the object code.


This would not conflict with the undecidability theorem since the
presence of pattern P is not a UUV as having the pattern does not mean
that the program *is* a virus, only that it *might be*. And part II
allows any honest program to be written and not be dubbed dangerous.

I'm actually mixing mathematics and technology in the above. The purely
mathematical conjecture would be (having defined "virus" in some
appropriate useful way): There is a decidable set W such that 1) all
programs containing viruses are in W and 2) all programs that do not
contain viruses *have an equivalent* (identical input-output behaviour)
that is not in W. Program equivalence is undecidable so this does not
contradict the undecidability of virus detection. The technological
part would consiuAof expressing W in some convenient way through
hardware architecture.

Is this plausible? Frankly, it doesn't sound so to me, but I wouldn't
discard it off hand. It's the only hope I see of some general
mathematical result being useful for anti-viral strategies, so maybe we
should look at it more closely.


 ----------------------------------------------------------------------
 George Svetlichny                 | When it is not your mother who is
 Department of Mathematics         | in danger of being eaten by a
 Pontificia Universidade Catolica  | wild animal, the matter can wait
 Rio de Janeiro, Brasil            | until the morrow.
                                   |
 [e-mail] Fido 4:4/998 |      Baganda Proverb
 ----------------------------------------------------------------------

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Monday, 12 Feb 1990    Volume 3 : Issue 38

Today's Topics:

copyrighted virus code?
Virus-laden Census Disks
The Aids Virus Author Caught (PC)
Re: Disinfectant 1.6 (Mac)
Re: WDEF A (Mac)
Re: Universal virus detector
RE: Copyrights on virus code
Re: Viruses 4096 and 1260 on BBS (PC)
Re: Idea for WDEF Innoculation (Mac)
Re: JERUSALEM B again (PC)
The AIDS "Trojan" is a Copy Protection System
Re: WDEF in Toronto (MAC)
Re: Idea for WDEF Innoculation (Mac)
Twelve Tricks Trojan (PC)
WDEF at Wollongong

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

---------------------------------------------------------------------------

Date:    Sat, 10 Feb 00 19:90:31 +0000
From:    [e-mail] (Greg Broiles)
Subject: copyrighted virus code?

 In VIRUS-L V3-36, Olivier Crepin-Leblond <[e-mail]> writes:

> In VIRUS-L V3-34 Steven C Woronick <[e-mail]> writes:
>
> >Even if you could copyright viral code, it's
> >not likely to discourage the kind of people who write viruses (aren't
> >those the ones you are really after?) from copying it.  Also, what
> >happens if some virus-loving person copyrights it before you do and
> >then grants universal privilege to copy?  Just wondering...

[text deleted]

> I can hardly imagine some individual copyrighting virus source code.
> Anyone doing that will probably be in for a lot of trouble...

Well, if it's written in the United States, it's copyrighted
automatically as soon as it's written to disk.  Anything "recorded in
a fixed medium of expression" is automatically copyrighted, with the
rights going to the author, unless she gives them up voluntarily.  No
registration is necessary (unlike patents), though it's helpful in the
case of a disputed claim of ownership.  Work done for an empoyer
belongs to the employer, not the employee.

I'm not a lawyer (I may end up as one someday) and I can't immediately
put my hands on a copy of the results of research I did on copyrights
a few years ago.  The above is correct, but might be incomplete.  At
any rate, I'm certain that, if Sam Sociopath locks himself up in a Las
Vegas hotel room and writes a virus, the copyright belongs to him.
(Unless he makes it public domain, transfers the rights, or is being
paid by another to write the virus.)

The United States has behaved strangely in the past in terms of
agreeing to and adherence to international treaties about copyrights.
Things may very well be different for viruses developed elsewhere,
though I doubt they could be copyrighted here.

------------------------------

Date:    Fri, 09 Feb 00 19:90:03 +0000
From:    email!lgdelta![e-mail] (SMSgt Michael L. Shamel)
Subject: Virus-laden Census Disks

The  following article is from the February 5, 1990  addition  of
COMPUTERWORLD.  I though the group might be interested.


U.S. RECALLS VIRUS-LADEN CENSUS DISKS.

     The Government Printing Office narrowly averted triggering a
nationwide computer virus epidemic late last month after  picking
up an infection from the U.S. Census Bureau.

     On  Jan. 25, the GPO was in the process of mailing  packages
containing  two floppy disks and a compact disc/read-only  memory
disc  holding census data to 772 depository  libraries  scattered
across  the country when it learned from the Census  Bureau  that
one  of the two disks had been infected by the  Jerusalem  virus,
said  Jan  Erickson, manager of information technologies  at  the
GPO.   The floppy disks contained programs that enabled users  to
retrieve  data from a CD-ROM disc published by the Census  Bureau
containing the County and City Data Book.

     The  Jerusalem  Virus,  also known as  the  Israeli,  Hebrew
University  and Friday the 13th virus attacks both .COM and  .EXE
files  on personal computers running under MS-DOS,  according  to
John McAfee, president of the Computer Virus Industry Association
in Santa Clara, Calif.

     The  virus repeatedly infects executable  files,  increasing
them  about 1.8K bytes, until the computer's memory  is  clogged,
McAfee  said.  In addition to slowing an infected  systems,  some
versions can destroy data, although that does not appear to  have
happened this instance.

     "The GPO's [distribution] system allows libraries to  choose
the  material  that they want, and of the  1,400  libraries,  772
chose  this disk," Erickson said.  "We caught most of  the  disks
before they went out."

     The few libraries that received the disks have not  reported
an problems with data being destroyed, she added.

     The  virus  was  initially discovered  on  four  stand-alone
computers in the Suitland, Md., office of the Data Users  Service
Division  of  the  Census Bureau on Jan. 22  and  was  eradicated
within 24 hours, said Jim Gorman, a Census Bureau spokesman.   It
is still unclear how the four computers were infected, he said.

     Two days later, on Jan. 25, the bureau discovered that disks
slated  to be distributed by the GPO had been infected  with  the
same virus, Gorman said.

     The  disks, however, were not produced by the Census  Bureau
but  by  an  outside  disk  duplication  service,  Gorman   said.
Furthermore, it is not known if the virus was transmitted by  the
Census Bureau to its disk supplier.

     Gorman  said  that  he did not know the  name  of  the  disk
duplicator  or what action, if any, the Bureau intended  to  take
against the firm.

     In  an alert sent out to its depository librarians, the  GPO
said  that it and the Census Bureau planned to take  "appropriate
measures  ... to ensure that it does not happen  again."   Gorman
said that he did not know what those measures would be.

     The virus had no impact on the Census Bureau's  preparations
for the 1990 census, Gorman said.

     The computer Virus Industry Association has put out an alert
about the virus to its members, warning them that the disk should
be  destroyed  immediately,  McAfee said.  The  virus  is  easily
transmitted and can destroy programs, he warned.

------------------------------

Date:    Sat, 10 Feb 00 19:90:34 +0000
From:    email!lgdelta![e-mail] (SMSgt Michael L. Shamel)
Subject: The Aids Virus Author Caught (PC)

The  following article is from the February 5, 1990  addition  of
COMPUTERWORLD.  The FBI apparently caught the guy who spread  the
Aids  Virus Disk in England.  Although this is more of  a  Trojan
Horse  than  a  Virus  story,  I  thought  the  group  might   be
interested.

SUSPECT ARRESTED IN AIDS DISK FRAUD CASE

     Acting on a warrant issued by a London magistrate, agents of
the  Federal  Bureau of Investigation arrested Dr.  Joseph  Lewis
Popp  last  Thursday  for his alleged role in a  scheme  to  bilk
computer users who used a program that he created.

     Popp,  an  U.S. citizen, is alleged to be the author  of  an
"AIDS   Information  Introductory  Diskette"  that   was   mailed
unsolicited  to  thousands of MS-DOS computer  users  in  Europe,
Africa and Australia last December.

     Concealed within the program, which was designed to evaluate
a   person's  likelihood  of  contraction  the  Acquired   Immune
Deficiency  Syndrome (AIDS) virus, was a Trojan horse that  moved
some  files  stored  on hard disks into  hidden  directories  and
encrypted others.

     "The effect for the nontechnical user is devastating because
it  appears  as though everything is gone,"  said  Jim  Bates,  a
computer consultant in Leicester, England, who has dissected  the
program.

     A license agreement packaged with the AIDS disk warned users
that  the  program  would  adversely  affect  programs  on  their
personal computer's hard disk drives unless they agreed to  lease
the program with 365 uses for $189, or for the "lifetime of  your
hard  disk" for $398.  Users were directed to send a check to  an
address  in  Panama  City, Panama.  It has  been  estimated  that
between  23,000  and  27,000 disks were  mailed  to  unsuspecting
users,  according  to Bates.  There have been no reports  of  the
programs's arrival in the U.S.

     English  law  enforcement authorities issued a  warrant  for
Popp's arrest on Jan. 15 for allegedly violating a 1968 blackmail
and extortion statute, said assistant U.S. Attorney Gary Arbeznik
in Cleveland.

     Popp,  39,  is  being held without  bail  following  a  bond
hearing  last  Friday.  It is not known  whether  he  will  fight
extradition  (hearings  are expected to be concluded  within  the
next 60 days).

     Popp,  who has a PH.D. in anthropology, is believed to  have
once  worked  for  the World  Health  Organization  (WHO),  whose
members were among those who received the AIDS disk.

     A  WHO spokesman in Washington, D.C. said that Popp  is  not
currently employed by the organization.

------------------------------

Date:    Sat, 10 Feb 90 13:41:16 -0800
From:    [e-mail]
Subject: Re: Disinfectant 1.6 (Mac)

>      I have recently read something about Disinfectant 1.6 from this
> newsgroup.  Its author said that there was no Disinfectant 1.6 and it
> maigt cause potential porblems on virus detection.  Someone in our lab
> downloaded it and has been using it without any obvious trouble.  I
> would appreciate any further comments on this application.  So, again,
> is there any upgraded version of Disinfectant after version 1.5 ?  If
> not, is there any more information about this "fake" Disinfectant ?

A month or so ago, there was a report of a Disinfectant 1.6 at a time
when the latest officially-released version of Disinfectant was 1.5.
It turns out that this report was in error... a fileserver somewhere
had a copy of 1.5, and had mistakenly catalogged it as being version
1.6.

More recently (about 10 days ago), John Norstad released an official
1.6 version of Disinfectant.  This version includes nVIR-clone
detection... it will identify and remove simple clones of the nVIR
virus family even if these clones are newly-created and have not been
seen before.

Check the version history in the About... box in the copy of Disinfectant
1.6 which you have downloaded.  If it's consistent with this description,
you probably have a valid copy of the new version, and can use it without
difficulty or dismay.

- --
Dave Platt                                             VOICE: [phone]
  UUCP: ...!{ames,apple,uunet}!coherent!dplatt   DOMAIN: [e-mail]
  INTERNET:       coherent![e-mail],  [e-mail]
  USNAIL: Coherent Thought Inc.  3350 West Bayshore #205  Palo Alto CA 94303

------------------------------

Date:    Sat, 10 Feb 90 13:47:41 -0800
From:    [e-mail]
Subject: Re: WDEF A (Mac)

+ Today, while I was disinfecting a Macintosh IIx with Disinfectant 1.6
+ I got a report saying that the desktop was infected at 3:36 p.m. on
+ 2/6.
+
+ Now, it just happened that it WAS 3:36 p.m. while I was doing the
+ disinfecting...
+
+ Since the locked disk was clean, it couldn't have infected the HD,
+ right?  The person involved swears that no other disks had been in his
+ drives today.

The time-of-infection which Disinfectant reports is the "last modification
time" for the infected file.  This information is often useful when
you try to track down a virus which infects applications, since most
applications do not modify themselves when they are run... and hence
the "last modification time" of the application will often be the time
at which the virus infected the program.

However, the Desktop file is modified _very_ frequently by the
Finder...  it may be modified any time you launch a new application,
or drag an application from one disk/folder to another, or change any
file's Get Info... comments.  For this reason, the "last modification
time" on the Desktop file is _not_ a reliable indicator of when your
system was first infected.

BTW, there's no reason (as far as I know) to install Gatekeeper Aid on the
locked Disinfectant disk... as long as you keep the disk locked, no virus
will be able to infect it.
- --
Dave Platt                                             VOICE: [phone]
  UUCP: ...!{ames,apple,uunet}!coherent!dplatt   DOMAIN: [e-mail]
  INTERNET:       coherent![e-mail],  [e-mail]
  USNAIL: Coherent Thought Inc.  3350 West Bayshore #205  Palo Alto CA 94303

------------------------------

Date:    Sat, 10 Feb 90 17:59:43 -0500
From:    [e-mail]
Subject: Re: Universal virus detector

Robert Eachus explained quite lucidly why there is no possibility of
building a universal virus checker WHICH PERFECTLY DISTINGUSIHES
BETWEEN VIRUSES AND NON-VIRUSES [emphasis mine].  As with most
theoretically intractable problems, a slight change in the question
leads to remarkably different results.  For example, it's entirely
feasible to build a virus checker which errs on the safe side and
throws out some good programs as well as all bad programs.  Whether
this is useful depends on how many good programs it throws out.  At
the extreme, you can postulate it throwing out ALL programs.  This is,
of course, the easiest filter to build, but also the least useful,
i.e. completely useless.  A more interesting challenge is whether you
can build a checker that permits a usefully large set of good
programs to be executed while excluding all bad programs.   A related
question is whether it's possible to define programming standards whic
facilitate the checking process.  If such standards existed, the
burden of proving that a program is virus-free would fall back on the
writer of the program.  Programs not meeting the criteria would be
treated the same as virus-laden programs and prohibited from execution.

Maria Pozzo is working in this area, and she and I published a paper
at the IEEE Symposium on Privacy and Security last year.  I also
posted a description of the basic ideas some time ago.  (Perhaps the
editor would be kind enough to supply the volume and number?)

------------------------------

Date:    Sat, 10 Feb 90 17:12:00 -0800
From:    [e-mail] (JAMES E. MOLINI)
Subject: RE: Copyrights on virus code

I have recently seen quite a bit of rhetoric about the possibility of
copyrighting virus code and thereby reducing the chance that some
innocent dolt would play with it and start an epidemic.  Although I
can easily believe the scenario, I can't accept the recommended
deterrent.

In particular, Olivier M.J. Crepin-Leblond appears to think that just
having the code is inherently dangerous and therefore should be tightly
controlled.  While I agree that there is not much to be done with virus
writers (aside from removing body parts), I cannot believe that
legislating virus code will provide any real benefit for the rest of
us.  Let's examine a similar situation.

How many of you reading this bulletin think that you know how to stick
up a liquor store?  If you don't know how, you will after watching a
couple episodes from "Cagney & Lacey" or some other appropriate
American Police show.  So as long as you know how, what prevents you
from trying it the next time you are a little short on cash?

If you live in Europe you might say that "It's just not done."  We here
in the U.S., however, are probably just as afraid that we will end up
spending a couple of years in a cell with a bisexual, 300 lb. (136 kg.)
dope pusher.  This is precisely the reason why Mike Royko (an American
humorist) felt that Robert Morris Jr. needed to do some jail time.
Prison is not nearly as much a deterrent for the hardened criminal as
it is for the college freshman and high school senior.

That is why I doubt that we will ever see it illegal to possess virus
code here in the U.S.  I would rather see us vigorously prosecute the
use of these things.  Which leads me to my last point.

The best way to start fighting this beast is to start reporting people
who engage in obviously illegal activity.  If you overheard hackers
sharing virus code at one of these gatherings, I would advise you to
report it to the sponsor of the event and have them thrown out.  A
conversation overheard at a public event is a perfectly legal tip for
the police too.  As long as these punks believe that their activities
will be tolerated, we will continue to be infected and damaged by these
things.

Jim Molini

------------------------------

Date:    Fri, 09 Feb 90 16:25:05 +0000
From:    [e-mail] (David Dyer-Bennet)
Subject: Re: Viruses 4096 and 1260 on BBS (PC)

[e-mail] (GEORGE SVETLICHNY) writes:
:What David forgets to mention is that the BBS is the safest source of
:virus-free files *as long as the BBS is infected* with these viruses.
:Will Sysops now start deliberately infecting their boards with these
:viruses so as to assure the users clean files? Is your BBS infected,
:Dave? ;-)

Not as of last weekend, the last time I ran scanv57.  Actually, I've
never *seen* a virus, nor have any other local sysops so far as I'm
aware (it hasn't been mentioned in the fidonet sysops echo, anyway).

Getting serious for half a second, the other problem is that most
software on a bbs is in archived form; if the files are infected
inside the archive wrapper, the virus won't disinfect itself when
reading them even if the bbs *IS* infected.  Oh well :-)
- --
David Dyer-Bennet, [e-mail]
or [e-mail]
or Fidonet 1:282/341.0, [phone] 9600hst/2400/1200/300
or terrabit![e-mail], ...{amdahl,hpda}!bungia!viper!terrabit!ddb

------------------------------

Date:    Sun, 11 Feb 90 20:35:44 -0500
From:    Christopher Tate <[e-mail]>
Subject: Re: Idea for WDEF Innoculation (Mac)

[e-mail] (Jason Ari Goldstein) says:

>I don't know much about Macs (Being a PC person) but if I understand
>correctly every time the disk is inserted the they Virus is sread to
>the disk.  Well, why doesn't someone write an innoculation directly
>based on the virus itself.  Everytime a disk is inserted in the drive
>it would be checked for infection if so it would remove WDEF if not it
>would then 'innoculate the disk' with itself.  Eventually, WDEF would
>be wiped out the same way it was spread initially.
>
>The only problem with this is that it is a virus also, but with the
>proper prompts (allowing the user the choice of being innoculated) I
>don't think this would be a problem.  I know I would mind not ever
>being infected by a virus that kills other viruses.
>
>In the mean time, about 75% of the time I in a cluster I remove WDEF A
>or B from either a hard disk or someone elses floppies.

The big problem with this is that since the WDEF-removal code is itself
a virus, it stands a big chance of causing the same problems as any other
virus -- crashes due to poorly written code.

There have been no viruses written to date for the Macintosh which
deliberately cause damage to the system (*).  All of the problems caused
by existing viruses are in fact the result of bugs in the viruses, which
causes interference with other programs under certain circumstances.
Since the above-mentioned inoculation program would be a virus itself,
it might well cause problems itself.

(*)  Mosaic and Font Finder are not viruses (they do not replicate), but
     are instead "trojan horses" -- destructive code hidden within an
     innocuous-seeming program.

- -------
Christopher Tate                       |
[e-mail]                    | nobody, not even the rain,
[e-mail]                   |   has such small hands.
 ..!psuvax1!psuvm.bitnet!cxt105        |

------------------------------

Date:    Sun, 11 Feb 00 19:90:24 +0000
From:    mcdphx!hrc!microm![e-mail]
Subject: Re: JERUSALEM B again (PC)

Definitely sound advice! This virus will try to attach itself to any
exe,com,app,or ovl file you run once it is in memory ... and as such
has the tendency to propagate quite quickly. The latest SCANxx can
usually be found quickest on a local DOS based BBS (it is sharware )
and has CLEANUP which will eradicate the virus. There is also alot of
interesting documentation that comes with it. The only problem is that
this paticular flavor of virus can not always be removed without some
damage to the original file ... but a least it can be removed!

I would be interested in knowing what the commercial package was ...
we have seen a few minor breakouts here in Phoenix lately.

I'm just a wanna be UNIX guru (IJWBUG)               | Micro Maintenance, Inc.
                                                     | 2465 W. 12th St. #6
           -== Brad Fisher ==-                       | Tempe, Arizona  85281
     ...!asuvax!mcdphx!hrc!microm                    | 602/894-5526

------------------------------

Date:    Mon, 12 Feb 90 10:45:03 -0500
From:    munnari!mqccsunc.mqcc.mq.oz.au![e-mail] (Ian Farquhar)
Subject: The AIDS "Trojan" is a Copy Protection System

For several weeks we have been monitoring the discussion in comp.virus
and elsewhere concerning the AIDS "trojan".  There has been much
discussion about the motives of the author in publishing this virus,
and the general surprise that the accompanying program was quite
sophisticated.

We have recently received a copy of the AIDS trojan with the
accompanying license agreement, and upon reading this agreement I am
drawn to make several points.  Needless to say, this copy was not
installed.  Let me quote some of the relevant passages from the
license agreement:

"Read this license agreement carefully.  If you do not agree with the
terms and conditions stated below, do not use the software, and do not
break the seal (if any) on the software diskette..."

"...you may not decompile, disassemble, or reverse-engineer these
programs or modify them in any way without consent from PC Cyborg
Corporation.  These programs are provided for your use as described
above on a leased basis to you; they are not sold.  You may choose one
of the following types of lease (a) a lease for 365 user applications
or (b) a lease for the lifetime of your hard disk drive or 60 years,
whichever is the lesser.  PC Cyborg Corporation may include mechanisms
in the programs to limit or inhibit copying and to ensure that you
abide by the terms of the license agreement and to the terms of the
lease duration.  There is a mandatory leasing fee for the use of these
programs; they are not provided to you free of charge.  The prices for
"lease a" and "lease b" mentioned above are US$189 and US$378,
respectively (subject to change without notice).  If you install these
programs on a microcomputer (by the install program or any other
means), then under the terms of this license you are thereby agree to
pay PC Cyborg Corporation in full for the cost of leasing these
programs.  In the case of breach of this license agreement, PC Cyborg
Corporation reserves the right to take any legal action necessary to
recover any outstanding debts payable to PC Cyborg Corporation and to
use program mechanisms to ensure termination of your use of the
program.  These program mechanisms will adversely affect other program
applications on microcomputers.  You are hereby advised of the most
serious consequences of your failure to abide by the terms of this
license agreement: your conscience may haunt you for the rest of your
life; you will owe compensation and possible damages to PC Cyborg
Corporation; and your microcomputer will stop functioning normally.
Warning: Do not use these programs unless you are prepared to pay for
them..."

End quote.

This is not a trojan: it is a COPY PROTECTION SYSTEM.  The
consequences of using the program without paying are quite adequately
laid out in the license, which apparently has not been read.  It warns
quite clearly that:

a)   You should not install this program unless you are going to
     pay for it.

b)   The program contains mechanisms that will ensure that the
     terms of this license agreement will be followed.

c)   That these mechanisms will affect other programs on the hard
     disk.

I am led to make the following conclusions:

1.   That all of the users who were adversely affected by this
     supposed trojan either (a) did not read the license
     agreement for the program which they were installing, or (b)
     they read it and ignored it.  Either way, they must accept
     the consequences.  The installation instructions first step
     tells you to read the agreement on the reverse of the sheet.

2.   That the people who have been harping on at length about
     this trojan did not bother to read the license agreement
     either.  I am left wondering if the "excitement" of this
     horrible "trojan" prevented them using some elementary logic
     to ask if the program may be something else.

3.   PC Cyborg laid out the consequences quite plainly in the
     license agreement.  It is a debatable point whether PC
     Cyborg would have sent the "defusing" program for the time
     bomb that this program installs, though the US invasion
     would have defeated any attempt to do this (the invasion was
     doubtless more illegal than this program).

4.   That the people hurriedly disassembling the program actually
     committed a breach of the license agreement, and are liable
     for legal action from PC Cyborg.  Equally, copying of this
     program is as illegal and is as much piracy as copying any
     commercial program.

I am stunned at the sheer volume of pointless garbage that this
program has generated, and it makes me seriously doubt any other
information received from these "experts".  I would also point out
that self-destructing programs are not new, but one has never caused
such an outcry before.

If the author of this program is convicted, it will be the first
conviction ever for the hidious crime of writing a copy protection
system, and will be one of the biggest farces of justice ever
witnessed.

Disclaimer:  These are my own opinions, and do not necessarily
             represent the opinions of my employers.

"AI is also an acronym for Artificial Ignorance"

Ian Farquhar                      Phone : [phone]
Office of Computing Services      Fax   : [phone]
Macquarie University  NSW  2109   Also  : [phone]
Australia                         Telex : AA122377

ACSNet [e-mail]  [e-mail]

------------------------------

Date:    09 Feb 90 02:29:05 +0000
From:    [e-mail] (Woodrow Baker)
Subject: Re: WDEF in Toronto (MAC)

[e-mail] (Kevin Adams) writes:
>
> >From the reports I've read NVIR and WDEF both have no malicious
> intent, and that any damage they cause are 'side effects'.  Is this
> accurate?
>
> It seems very strange to me that Virus writers would launch
> their missiles with no payload...

Not really,  Perhaps they are
1.      General test cases to see how effective an attack method is
2.      A somewhat responsible virus writer, who likes the chllenge
        but would not want to cause damage.
3.      Someone who stood a chance f getting discovered, and figured
        that if it was a benign virus, the legal troubles would be less.

All of the above would be valid reasons not to make it lethal...
Cheers
Woody

------------------------------

Date:    09 Feb 90 02:33:21 +0000
From:    [e-mail] (Woodrow Baker)
Subject: Re: Idea for WDEF Innoculation (Mac)

[e-mail] (Jason Ari Goldstein) writes:
> Just like everywhere else the WDEF is thriving here at Carnegie-Mellon
> Univ.  I recently removed WDEF A & B off of 15 disks of a friend of
> mine.  When I commented to somone here about the virus they said there
> was nothing they could do to stop it, except remove it once a machine
> got infected.
>
> I don't know much about Macs (Being a PC person) but if I understand
> correctly every time the disk is inserted the they Virus is sread to
> the disk.  Well, why doesn't someone write an innoculation directly
> based on the virus itself.  Everytime a disk is inserted in the drive
> it would be checked for infection if so it would remove WDEF if not it
> would then 'innoculate the disk' with itself.  Eventually, WDEF would
> be wiped out the same way it was spread initially.

This is the first *really* sane Idea that I have seen, about
combatting viri.  The checkers and clearers are fine, but this type of
'virus' would be a good thing.  Provided it is safegarded so that IT
can't be infected.....

Cheers

Woody

------------------------------

Date:    Mon, 12 Feb 90 10:45:43 +0000
From:    Alan Solomon <[e-mail]>
Subject: Twelve Tricks Trojan (PC)

The "Twelve Tricks" trojan - alert and description

We have recently received and analysed a trojan that we believe
warrants an urgent alert.  We are calling it the Twelve Tricks trojan,
and it is very interesting, very nasty, and quite complex.  This
message is not meant to be a complete description of the trojan - we
feel that it is important to get a warning out quickly, rather than
aim for completeness.  It is not a virus.

The trojan consists of a program (more about this aspect later) which
you run;  running the program, as well as the obvious things that the
program is expected to do, also replaces the partition record (also
called the Master Boot Record, or MBR) on your hard disk with its own
version.  This can easily be recognised by inspecting the hard disk at
cylinder zero, head zero, sector one, which can be done with a disk
sector editor such as Peeka.  If the partition has this trojan in
place, it will contain the following text near the beginning:

SOFTLoK+ V3.0 SOFTGUARD SYSTEMS INC
2840 St. Thomas Expwy,suite 201
Santa Clara,CA 95051 [phone]

At this point, let us state that we believe that the company mentioned
above has nothing whatsoever to do with the trojan;  perhaps the
trojan author has a grudge against them.

The trojan uses a far call to the hard disk Bios code in order to
plant this partition.  To do this, it must know the location in memory
of the entry point;  it tries five different ones, one of which is the
one documented in the IBM PC-XT Technical reference manual, and the
other four are presumably fairly common alternatives.

The purpose of planting the trojan with a far call is, we believe, to
escape detection by Active Monitor programs that protect a computer by
monitoring the interrupt table, and preventing unauthorised writes to
system areas on the hard disk.  Since Twelve Tricks doesn't use an
interrupt to plant the MBR, such programs won't be able to prevent it.
We tested this using Flushot+, probably the most successful of the
Active Monitors, and Twelve Tricks went straight through it - the same
would be true, we think, of any other Active Monitor.

The Replacement MBR

When the MBR is run, which is every time you boot from the hard disk,
Twelve Tricks copies 205 (d7h) bytes of itself onto locations 0:300h
to 0:3d6h.  This overwrites part of the interrupt vector table, but it
is a part that doesn't get used very much.  This means that these d7h
bytes are memory resident without having to use any of the TSR calls
of Dos, and without having to reserve part of high memory.  Reserving
part of high memory is the usual ploy used by Boot Sector Viruses, but
the drawback of that route is that you might notice that a few kb from
your 640 kb has disappeared (CHKDSK would reveal this).  The method
used by Twelve Tricks would not show up as a loss from your 640 kb.

When the computer is started up, a random number generator determines
which of the Twelve Tricks will be installed.  It does the
installation by replacing one of the interrupt vectors with a vector
that points to the Twelve Tricks own code, and then chains on to the
original code.  The twelve tricks are:

1.  Insert a random delay loop in the timer tick, so that 18.2 times
per second, the computer executes a loop that is randomly between 1
and 65536 long (different each time it is executed).  This slows the
machine down, and makes it work rather jerkily.

2.  Insert an End-Of-Interrupt in the timer tick.  This interferes
with the servicing of hardware interrupts, so for example, the clock
is stopped, TSRs that depend on the timer tick don't work, and the
floppy motor is permanently on.

3.  Every time a key is pressed or released, the timer tick count is
incremented by a random number between 0 and 65535.  This has a
variety of effects;  programs sometimes won't run, when you type
"TIME" you get "Current time is divide overflow", and copying files
sometimes doesn't work.

4.  Every time interrupt 0dh is executed, only do the routine three
times out of four.  Interrupt 0dh is used on PCs and XTs for the fixed
disk, on ATs for the parallel port.

5.  Every time interrupt 0eh is executed, only do the routine three
times out of four.  Interrupt 0eh is used for the floppy disk.

6.  Every time interrupt 10h is called (this is the video routine),
insert a delay loop that is randomly between 1 and 65536 long
(different each time it is executed).  This slows the video down, and
makes it work rather jerkily and/or slowly.

7.  Every time the video routine to scroll up is called, instead of
the requested number of lines being scrolled, the entire scrolling
window is blanked.

8.  Every time a request is made to the diskette handler, it is
converted into a write request.  This means that the first time you
try to read or write to a diskette, whatever happens to be in the
buffer will be written to the diskette, and will probably overwrite
the boot sector, FAT or directory, as these must be read before
anything else can be done.  If you try to read a write protected
diskette, you get "Write protect error reading drive A".  If you do a
DIR of a write enabled diskette, you get "General Failure ...", and if
you inspect the diskette using a sector editor, you'll find that the
boot and FAT have been zeroed or over-written.

9.  Every time interrupt 16h is called (read the keyboard) the
keyboard flags (Caps lock, Num lock, shift states etc) are set
randomly before the keystroke is returned.  This means that at the Dos
prompt, the keyboard will only work occasionally.  Programs that poll
interrupt 16h will be unusable.  Holding down the Del key will trigger
a Ctrl-Alt-Del.

10.  Everything that goes to the printer is garbled by xoring it with
a byte from the timer tick count.

11.  Every letter that is sent to the printer has its case reversed by
xoring it with 20h.  Also, non-alpha characters are xored, so a space
becomes a null, and line feeds don't feed lines.

12.  Whenever the Time-Of-Day interrupt (1ah) is executed, do an
End-Of-Interrupt instead.  This means that you can't set the system
clock, and the time is set permanently to one value.

These are the twelve tricks.  In addition there are two more things
that the trojan does.  It uses a random number generator;  one time
out of 4096, it does a low level format of the track that contains the
active boot sector;  this will also destroy part of the first copy of
the FAT.  You can recover from this by creating a new boot sector, and
copying the second copy of the FAT back over the first copy.  After it
does the format, it will display the message "SOFTLoK+ " etc as above,
and hang the computer.

If it doesn't do the format, it makes a random change to a random word
in one of the first 16 sectors of the FAT, which will make a slight
and increasing corruption in the file system.  This is perhaps the
worst of the things that it does, as it will cause an increasing
corruption of the files on the disk.

The Dropper program

The program that drops the trojan was, in the specimen that we
analysed, a hacked version of CORETEST, a program to benchmark hard
disk performance.  The file is CORETEST.COM, it is version 2.6, (dated
1986 in the copyright message) had a length of 32469 bytes, and it was
timestamped 6-6-86, 9:44.  When we looked in more detail at this
program, we found some interesting things.

It looks as if the original CORETEST program was an EXE file, and the
trojan author prepended his code to it.  This code consists of some
relocation stuff, then a decryptor, to decrypt the following 246h
bytes.  The decryption is a double xor with a changing byte.  Those
246h bytes, when run, examine the memory to try to find one of five
sets of hard disk handler code (presumably corresponding to five
Bioses).  When it finds one of them, (we have identified the first one
as being the IBM XT Bios) it plants the trojan MBR in place, using a
far call to the Bios code.  The trojan MBR is 200h of the 246h bytes.
The trojan is patched so that it also does disk accesses using a far
call to the same location.  Finally, the prepended trojan passes
control to the original program.  We call the combination of the
prepended code, plus the original program, the Dropper.

The main purpose of the encryption, we would guess, is to evade
detection by programs that check code for bombs and trojans. There
are no suspicious strings or interrupt calls in the code until it
is decrypted at run time.

As far as we can tell, it is not a virus, but a trojan.  However, it
is unlikely that all the patching to the original program was done by
hand - it is far more likely that the trojan author wrote a prepender
program (we would call this the Prepender), to automatically attach
his code to the target executable.  If this is the case, then there
are two consequences.  The first is that he might have trojanised
other programs besides the one that we have examined.  In other words,
there might be other Droppers around besides the one we have examined.
The second is that if that is the case, we cannot rely on the
encryption having the same seed each time, as the Prepender might
change the seed each time it operates.  So it would be unsafe to
search files for the encrypted MBR.  Instead, we propose a search
string based on the decryptor.

Indeed, a further possibility exists.  The Prepender program might
have been placed into circulation, and people running it would
unwittingly be creating additional Droppers.  There is absolutely no
evidence to suggest that that is actually the case, but we would ask
anyone who detects this Dropper in one of their files, to also examine
all the others.

Detection

Here's a variety of ways to detect the trojan. The hexadecimal string
e4 61 8a e0 0c 80 e6 61 is to be found in the MBR. This string will
also be found in memory if you have booted from a trojanised MBR,
at location 0:38b. You can use Debug to search in memory.

A useful search string to detect the Dropper is

be 64 02 31 94 42 01 d1 c2 4e 79 f7

Getting rid of it

It's easy to get rid of Droppers;  just delete them and replace them
with a clean copy.  If you find the string above in the MBR or in
memory at 0:38b, you need to boot from a clean Dos diskette and
replace the partition record.  DO NOT use Fdisk to do this unless you
are prepared for Fdisk to zero your FAT and directory;  you will lose
all your data that way.  One way would be to do a file-by-file backup,
low-level format to get rid of the trojan MBR, then Fdisk Format and
restoer your backup.  We would recommend doing two backups using as
different methods as possible if you use this route, in case one of
them fails to restore.

The other way to replace the partition is to run a program that drops
a clean partition record onto the MBR, but doesn't change the
partitioning data.  We are currently preparing one of these - please
ask if you need it.

Damage done

The whole of the MBR is used for the code.  Most normal MBRs don't use
more than half the space, and a number of other programs have started
using this space.  For example Disk Manager, and the Western Digital
WDXT-Gen controllers (but the Dropper doesn't work on the WDXT-Gen).
This means that the Dropper might cause an immediate problem in some
circumstances.

The main damage done, however, will be in the impression that this
trojan creates that your hardware is suffering from a variety of
faults, which usually go away when you reboot (only to be replaced by
other faults).  Also, the FAT gets progressively corrupted.

Occurrences

So far, this has only been reported in Surrey, England.  It was
noticed because it made a disk using Speedstor to control it,
non-bootable.  Disks that are controlled in the normal way, remain
bootable.  We would be grateful if any sightings could be reported to
us, especially if the Dropper program is different from the one we
have examined;  we would also like a specimen of it,

Please report instances to the addresses below:

Dr Alan Solomon                Day voice:     [phone]
S&S Anti Virus Group           Eve voice:     [phone]
Water Meadow                   Fax:           [phone]
Germain Street,                BBS:           [phone]
Chesham,                       Fido node:     254/29
Bucks, HP5 1LP                 Usenet:        [e-mail]
England                        Gold:          83:JNL246
                               CIX, CONNECT   drsolly

or

Mr Christoph Fischer           Day voice:     [phone]
Micro-BIT Virus Centre         Eve voice:     [phone]
University of Karlsruhe        Fax:           [phone]
Zirkel 2                       BITNET:        RY15@DKAUNI11
D-7500 Karlsruhe 1
West-Germany

------------------------------

Date:    12 Feb 90 18:14:22 +0000
From:    "David N. Schlesinger" <[e-mail]>
Subject: WDEF at Wollongong

For those who are keeping scores, the WDEF virus has been found on at
least two Macs at the Wollongong group.  It was found and destroyed
using Virex 2.3.

Best,

Lefty

===========================================================================
          David N. Schlesinger   || "There's a word for it: words don't
          The Wollongong Group   ||  mean a thing.  There's a name for it;
Internet: [e-mail]          ||  names make all the difference in the
POTS:     415/962-7219           ||  world..." -- David Byrne
===========================================================================

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Tuesday, 13 Feb 1990    Volume 3 : Issue 39

Today's Topics:

None other than WDEF (Mac)
Identification strings
Desktop Fractal Software Infection Confirmation
WDEF A strikes again. (Mac)
Virus Discussion on America Online
Re: The AIDS "Trojan" is a Copy Protection System
Arrayboundcheck in C
Re: Universal virus detector / Biological analogy
RE: Copy Protection on AIDS Diskette

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

---------------------------------------------------------------------------

Date:    Mon, 12 Feb 90 13:03:00 -0500
From:    Down & Out <[e-mail]>
Subject: None other than WDEF (Mac)

        I noticed a couple of messages in the list recently that asked
about WDEF and servers. I also noticed talk about programs to defeat
all known viruses. I also noticed that Wayne State reportd being hit.
(I notice alot of things). So let me say this..... 1. Albion could
have possibly gotten WDEF from Wayne State (We are located South
Central MI) 2.Macserve@Pucc has a fairly good listing of virus
protection and some general info on viruses 3.Here is a letter that I
sent to the creator of Eradicate'em, a protection program for WDEF.


<From:  PURPLE::KIP          "Down & Out"  8-FEB-1990 03:47:50.77
<To:    IN%"[e-mail]"
<CC:    KIP
<Subj:  Many thanks
<
<       I am a student at Albion College, Albion, MI. We have a
<computer lab that, along with other machines, contains 10 Macintosh
<Plus computers. The Machines run of of an 800k floppy and a 75meg
<nouvell server (run on an IBM).  The server also connects 10 IBM's.
<Ayway to my point, on 2/4/89 I was working in the lab when a person on
<an IBM had trouble loading a program. Well I am a tried and true Mac
<user so I had a friend look at it. It seemed that there was no memory
<on the server. We usually have about 40megs free. I thought well maybe
<the stupid IBM was reading the memory wrong. Well the Mac's said the
<same. Now I panicked. Scanning the room quick I notice on of the Mac's
<has a note on it saying "this disk infected with WDEF do not use". (we
<are currently running SAM as detection) Well the first thing I did was
<try to free up some memory space by trashing some files we did not
<need. I cleared up about 8k and was looking to see what else i could
<trash. Then all of a sudden the 8k was gone. It had eaten the free
<memory. Well the only thing I could think had happened was that WDEF
<had been transfered somehow from the floppy to the servers desktop. So
<I held down the option and command key on boot and when prompted "do
<you wish to rebuild the desktop on 'albionsys1'" I clicked on "Okay".
<Well it cleared up 75k immediatly. Then I started looking around and
<the other 40megs just seemed to reappear. This was a very strange
<occurance. I don't know if it was WDEF or just a coincidence. In my
<time of need i turned to "macserve@pucc" and began to download virus
<protection material.( the reason being sam is great for the regular
<user but the novice tends to push continue and not tell an assistant)
<In my time of need I found Eradicatem (nice icon by the way). It is
<now loaded on all of our Mac's in the lab and the computer club will
<also be circulating it. We did run tests with the copy of WDEF that we
<captured and were pleased at the actions.  (not that we did not
<believe you but we had to see what it did in a real life test). So
<thank you very much. Any questions you have on the occurance, or copy
<of WDEF (if you are interested) let me know. The lab is in debt to
<you.

Hope this helps anyone that is out there watching the movement and
effects of WDEF.

   ******************************************************************
   * [e-mail]                          * All comments made *
   * A concerned Mac user and fighter against   * in the above are  *
   * dasterdly virus through the implementation * mine. But who am  *
   * of the brillance of others.                * I ? (disclaimer?) *
   ******************************************************************

------------------------------

Date:    12 Feb 90 00:00:00 +0000
From:    "David.M..Chess" <[e-mail]>
Subject: Identification strings

Fridrik S.:

>  How about:
>
>         Identification string: A sequence of bytes, used by anti-virus
>         programs to check if a program is infected.
>
>         Signature string: A sequence of bytes, used by the virus to check
>         if a program is infected.
>
> Comments ?

Well, by an unhappy coincidence, we tend to use the terms more or less
the other way around, around here.  We call the thing that a virus
checks for the "self-identification", and we call the things that our
scanner scans for "signatures".  (The self-identification, by the way,
isn't always a string of bytes; it can be a bit-pattern in the
timestamp, or just about anything else!)  Note sure what to suggest to
solve the problem; perhaps people can just stop to spell out what they
mean when there's danger of ambiguity?

DC

------------------------------

Date:    Mon, 12 Feb 90 15:04:04 -0500
From:    "Jill A. O'Neil" <[e-mail]>
Subject: Desktop Fractal Software Infection Confirmation

In reply to:
>From:    Eric Roskos <[e-mail]>
>Subject: Re: "Desktop Fractal Design System Not Infected"

>.......... that to
>date there is no evidence *which has been presented on VIRUS-L* that the
>Desktop Fractal Design System, as shipped from the publisher, is
>infected.

Here's evidence.  An employee at my company purchased the Fractal
software directly from Academic Press via phone order.  When he placed
the call he was told that the order would be delayed a few days until
the second printing was complete.  When he received the diskette, it
was indeed infected with the Jerusalem-B virus. The virus was
identified by McAfee Associates VIRUSCAN.  The diskette was scanned on
a standalone (diskless) PC and we used McAfee's CLEAN55 to disinfect
the affected PC.

> There is only the claim that it is, and the statement
>(secondhand) that the publisher is "aware" of the problem.

Once it was determined that the Fractal software diskette was
infected, I (as Security Administrator for my work location) called
Academic Press (800-321-5068).  The person that answered the phone did
not have any details about the infection other than to say that yes
they are aware of the problem and that the diskette will be replaced
if the infected one is returned to them at the following address: 465
So. Lincoln Drive, Troy, Missouri 63379

   Academic Press also gave me a phone number for Iterated Systems
to call if I wanted further details.  When I called the number, I got
no answer (I tried the number several times a day for a week).  I also
called the customer service number listed on the warranty and again
got no answer (also called several times a day for a week).

   Several days after the above, the person who had the infected diskette
received a letter from Academic Press. The first paragraph is as follows:
   "Dear Customer,
    You recently purchased a software package from Academic Press
    THE DESKTOP FRACTAL DESIGN SYSTEM written by Michael Barnsley
    of Iterated Systems, Inc.  If the outside of your package has
    a round sticker in the upper right hand corner which says "VGA
    AND CGA COMPATIBLE", the enclosed disk is suspected of carrying
    a computer virus.  If there is no sticker on the outside of
    your package, the disk you received is not defective."

 The letter goes on to say that AP will replace the software with a
"clean version" and that they will "have an expert contact you to discuss
remedies in case you have infected your computer system".

>It would be helpful to those of us who have to deal with these issues to
>know more about details of alleged virus infections, things such as:

>       - Did you personally open and install the infected disk?

No I did not; however, the software was run from the diskette, not
installed on the hard drive.  The machine on which it was run had
not had any software updates in over 3 months (implying that the virus
was not previously introduced on the system via other software)
and only those executables that had run after the Fractal software
was executed became infected with the Jerusalem-B virus.
   The owner of the fractal disk also copied but DID NOT RUN the Fractal
diskette on his own PC at home (this was done prior to his bringing it
to the office).  VIRUSCAN found the Jerusalem-B virus in the fractal
executable only - no other files on his PC were infected.

>- Did you write-protect the disk before doing so?

unknown but probably not.

>- How many copies do you have that you know to be infected?

One.
A sitewide desktop distribution was done hours after the virus
confirmation but no other employees came forward saying they had
purchased this software.

>- What is the version number of the software?  Is there any other
>  date or serial number information involved?

Serial Number 03276
   The only other piece of identification is the VGA and CGA
compatible sticker on the outside of the package of the 2nd printing
of this software that was mentioned above in the letter from Academic
Press.

Jill A. O'Neil
Bitnet: jaoneil@erenj

------------------------------

Date:    Mon, 12 Feb 90 17:28:00 -0500
From:    "An adept of T'Pel." <[e-mail]>
Subject: WDEF A strikes again. (Mac)

In case anyone's keeping track, I spotted WDEF A on an internal hard
disk plus three other system disks in the Academic Computing Labs here
at Xavier University (Cincinnati, Ohio) using Disinfectant 1.5.  I've
informed my superiors and will warn my co-workers of this.

Tom Kummer

------------------------------

Date:    Mon, 12 Feb 90 17:27:55 -0600
From:    "McMahon,Brian D" <[e-mail]>
Subject: Virus Discussion on America Online

Readers with access to the America Online service might be interested
in the forum discussion announced for 22:00 EST on Saturday, 17 Feb;
the forum is titled, "Viruses: Hex or Hype?," keyword FORUMAUD, and
claims to feature a "real-live virus writer (who will remain
anonymous)."

Could be interesting.  As far as the anonymous bit goes, I think I'll
withhold judgement until Saturday.  Certainly, there will (should) be
questions for the moderators as well . . .

Brian McMahon  <[e-mail]>
Grinnell College
Grinnell, IA 50112

Usual and customary disclaimer, my opinions only ... (mumble)

------------------------------

Date:    Mon, 12 Feb 90 21:58:15 -0500
From:    [e-mail]
Subject: Re: The AIDS "Trojan" is a Copy Protection System

     In Virus-L 3:38 Mr. Ian Farquhar defended the AIDS "trojan" by
stating that it was only a copy protection system and that users were
properly warned.  I would like to counter his remarks with a few
thoughts:

 1) The AIDS disk did not have copy protection at all.  Copy protection is,
    by definition and tradition, a mechanism that attempts to prevent
    unauthorized copies from being made.  It is not a system that seeks out
    and hides (or even destroys) the user's files that have nothing to do
    with the software package in any way.  Those unrelated files belong to the
    user and it is the user which has the right to decide which software
    packages should have access to them.  I'd hate to think what it would be
    like if any form of "copy protection," no matter how draconian, could
    enjoy complete legal protection.

 2) The disks were unsolicited.  It is my uderstanding that none of the
    organizations that were mailed disks asked for them, and therefore had
    no way to learn about the software unless they actually used them.  In
    the US unsolicited objects received by mail are gifts, therefore, the
    so-called license agreement is void (and may possibly be illegal).  (Yes,
    I know "you should never look a gift horse in the mouth.")  I don't know
    how the laws are in the nations that were infected but its very likely
    that they are similar to those of the US.  I would even wager that the
    aforementioned postal regulation could be one of the reasons that the
    disk's instructions stipulated that the software could not be used in
    the United States.

 3) The market to which the disks were targeted was especially sensitive.
    It is very likely that vital medical records could have been tampered
    with by the AIDS disk, since medical organizations were the ones that
    received copies.  If the author was truly professional, I'm sure he/she
    would have marketed the package through conventional means (i.e. demo
    disks, advertising, etc.)  Of course this aspect may not be applicable
    to the alleged author, if in fact his judgement has been impaired by his
    psychological problems and/or treatment.

                                            David R. Brierley
                                            [e-mail]

------------------------------

Date:    Tue, 13 Feb 90 10:17:52 +0000
From:    "Dr. A. Wood" <[e-mail]>
Subject: Arrayboundcheck in C

This is not a virus as such; but program mishaps cause more system
upsets and loss of data than viruses do, and users should eliminate
all other causes of error before definitely suspecting a virus. One
main cause of mishaps is writing to arrays out of bounds. In Fortran
and Algol60 and Algol68 and similar, writing a compiler so it can
compile in array bound check mode is easy; but C can step pointers
along by adding arithmetic values, which complicates the job a lot. I
don't know if there are any C compilers with full arraybound check,
but Prime's C compiler hasn't got one. Bound checking array accesses
is easy; the problem is bound checking pointer accesses.  I hereby
submit a possible method of bound checking pointer accesses in C
programs.

In C, I define a <table> as any group of stored values of all the same
type which are all adjacent in store. There are these types of
tables:-

(1) <Arrays> declared at compile time with [ ] . E.g. 'int x[12],y[4][7];'.
A pointer to an array is created by one of these forms:-
a) An array element preceded by '&', e.g.               &x[i]    &y[5][j+k]
b) An arrayname followed by 'too few' subscripts, e.g.           y[h]
c) An arrayname without subscripts, e.g.                x        y
The arrayname can be some compound form such as a struct field or the like,
e.g. 'struct {int a; char[12]c; } z; ------ z.c' .

(2) <Allocations> alias <mallocks> created by calls of malloc() and
similar functions, which return a pointer to the allocation thus
created.

(3) <Runs>, i.e. consecutive members of a struct which are all of the
same type, e.g. 'x,y,z' in 'struct density {float x,y,z; double value;
} den;'. Pointers to them are created by prefixing a '&', e.g.
'&den.y'.

(4) Other cases where users are tempted to step a pointer over several
values, e.g.  'a,b,c,d' in the declaration 'double a,b,c,d;', are
compiler dependent and I will not consider them further.

My suggestion is for all pointer values to be accompanied by two other
pointer values which contain its safe range limits. (Thus
sizeof(<pointer type>), which == 6 in Prime C ordinarily, will become
18 in Prime C compiled in array bound check mode.) Examples are:-

declaration assumed     pointer value lower limit        upper limit  type
int x[4];               &x[3]         &x[0]              &x[4]        int*
int x[4];               x             &x[0]              &x[4]        int*
int y[6][7];            y[i]          y[0]               y[6]         int**
struct(int w,x,y,z;}a;  &a.x          &a.w               &a.z+1       int*
int k;                  malloc(k)     (returned value) (same + k bytes)
int s; /* not table */  &s            &s                 &s+1         int*

Procedure in the various uses of pointers:-    (Here, b and c are pointers)
sort of use                 example   procedure
accessing value pointed at  *b        check that b is within its limits.
pointer +- integer          b+i       check that b+i is within limits of b;
                                      copy limits of b as limits of b+i .
pointer with ++ or --       b++       (ditto)
pointer-pointer             b-c       error unless b and c have same ranges.
pointer[integer]            b[i]      treat as *(b+i) .
casting a pointer           (float*)c if casting to a pointer to a pointer, or
                                      to a pointer to a struct with a pointer
                                      member, the compiler should moan that
                                      "array bound check can't help here".

A pointer to an allocation which is lost by a call of 'free()', will
then be invalid.  Best not to call 'free()' when running in array
bound check mode.
- ----------------------------------------------------------------------
This should ensure that any pointer will only point to within the
bounds of the table that it was intended to point to.
{A.Appleyard} (email: [e-mail]), Tue, 13 Feb 90 08:38:40 GMT

------------------------------

Date:    13 Feb 90 04:20:25 +0000
From:    Mark Wilkins <[e-mail]>
Subject: Re: Universal virus detector / Biological analogy

[e-mail] (Dr. A. Wood) writes:

>        there have been a few 'biological analogy' articles
>in Virus-L before. This analogy will not work - biological immune
>systems are set up in a different way.

[stuff deleted]

>Also, any two bodies' cells (except identical twins) have different
                                                      ^^^^^^^^^^^^^^
>immunotypes, and attempted grafting fails, thus any bacterium that
 ^^^^^^^^^^^
>learns to masquerade as a legal cell of body A, is rejected on trying
>to invade body B. The computer analogy of this would be for each
>individual microcomputer's copy of each authorized program to be
>different.

   First, identical twins are not the only humans with identical
immunotypes.  Any individual's full brother or sister has a 1/4 chance
of having an exactly identical immunotype, or rather just slightly
less because of crossing-over.  But that doesn't belong in this group.

  This, however, does: It is true that tissue typing analogies are
poor for computerized anti-invasive agents.  However, the body's
system might provide some clues regarding possibilities for such
things.

  Suppose one wants to implement a system which, like the human body,
is adaptive.  How about this: Each low level write call causes a
checksum of the data written to be computed, or, better, the checksum
is computed 12 hours of uptime later, to avoid some shrewdly-done
virus from writing the data out in some randomized fashion.

  This checksum is then stored and indexed with the program or
programs which made the alterations leading to them. If the same
checksum starts cropping up repeatedly in calls from several different
programs which have never before exhibited such behavior then that
indicates that some uniform, self-replicating piece of code MIGHT have
infected those programs.

  Of course, there are likely to be cases where changes in system
configuration will cause this to happen, but all this routine would do
is produce a log from which a reasonably technically competent
individual could detect the infection.

  There might, also, be ways to improve it to actually prevent
spreading under certain circumstances.

- -- Mark Wilkins
   [e-mail]

------------------------------

Date:    Mon, 12 Feb 90 22:25:00 -0800
From:    [e-mail] (JAMES E. MOLINI)
Subject: RE: Copy Protection on AIDS Diskette

About the AIDS Trojan disk, Ian Fahrquar writes:

> This is not a trojan: it is a COPY PROTECTION SYSTEM.  The
> consequences of using the program without paying are quite adequately
> laid out in the license, which apparently has not been read.  It warns
> quite clearly that:
>
> a)   You should not install this program unless you are going to
>     pay for it.
>
> b)   The program contains mechanisms that will ensure that the
>     terms of this license agreement will be followed.
>
> c)   That these mechanisms will affect other programs on the hard
>     disk.

> I am led to make the following conclusions:

> 1.   That all of the users who were adversely affected by this
>     supposed trojan either (a) did not read the license
>     agreement for the program which they were installing, or (b)
>     they read it and ignored it.  Either way, they must accept
>     the consequences.  The installation instructions first step
>     tells you to read the agreement on the reverse of the sheet.
...
> If the author of this program is convicted, it will be the first
> conviction ever for the hidious crime of writing a copy protection
> system, and will be one of the biggest farces of justice ever
> witnessed.

Although I am not a lawyer (Thank God) I can say that the PC Cyborg
license agreement is inherently flawed.  It is the old principle of
"My privilege to swing my fist stops at the end of your nose."

Although the program could have erased itself and called the user all
sorts of nasty names, it had no right to hold his hard disk hostage.
Even if I notify you that I will burn down your business if you fail
to pay off the money you owe me, it still does not cause my action to
become suddenly legal.  That is why we have a court system and
thousands of over employed lawyers today.  You are supposed to settle
contract disputes in court, not with a high tech version of vigilante
justice.

The end result of all this is that the user was not EXPLICITLY made
aware of the absolutely catastrophic consequences of his/her actions.
As some of us have seen in the past, hiding things in fine print and
obscure wording is often sufficient reason to show that the signer did
not know what he was signing.

If you don't believe me, call a lawyer and ask him if he would
represent you on a contingency fee basis (you don't pay unless he
wins) for something like this.

And speaking of wasting someone's time.  Maybe we'd all bettter stop
trying to be what we aren't and concentrate on being a little better
at bug hunting and virus busting.  I will if you will.

Jim Molini

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Tuesday, 13 Feb 1990    Volume 3 : Issue 40

Today's Topics:

RE: AIDS Trojan - self protection
The ethics of virus eradication
VSUM9002.ZIP (PC)
Copyrights
Many WDEF reports (Mac)
Re: The AIDS "Trojan" is a Copy Protection System
The AIDS "Trojan" is a Copy Protection System
Re: WDEF and AppleShare (Mac)
Re: Re universal detectors.
Re: Signature Programs

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

---------------------------------------------------------------------------

Date:    Tue, 13 Feb 90 09:49:01 -0500
From:    woodb!scsmo1![e-mail]
Subject: RE: AIDS Trojan - self protection

> 1.   That all of the users who were adversely affected by this
>      supposed trojan either (a) did not read the license
>      agreement for the program which they were installing, or (b)
>      they read it and ignored it.  Either way, they must accept
>      the consequences.  The installation instructions first step
>      tells you to read the agreement on the reverse of the sheet.

  I agree, this is the most common practice.  You get this great
software and you want to see it RIGHT NOW!  Well, one DOES need to
read those agreements and take them at face value.

> I am stunned at the sheer volume of pointless garbage that this
> program has generated, and it makes me seriously doubt any other
> information received from these "experts".  I would also point out
> that self-destructing programs are not new, but one has never caused
> such an outcry before.

Agree... but...  Self-destructing programs should and generally only
destruct THEMSELVES!  If you rent-to-own a tv from 'Bob's Rent-to-own'
and don't pay Bob anymore to use the tv, Bob HAS the right to come and
get his tv.  But because you didn't pay for the tv, this does NOT give
Bob the right to take your whole house!

If this AIDS program was in the up and up he would have sent out
requests for the program.  It would have saved him money, time and a
whole lot of headaches.  His method WAS blackmail and he should get
all the jail time and penalties comming to him!


 DON INGLI-United States Department of Agriculture - Soil Conservation Service
 INTERNET: scsmo1![e-mail]    PHONEnet: 314!875!5344
 UUCP(short): uunet!scsmo1!don        UUCP(long): uunet!mimsy!woodb!scsmo1!don
              These are my opinions. I represent myself.
   Who do you think you are, Bjorn Nitmo?  David Letterman '90 Catch Phrase

------------------------------

Date:    Tue, 13 Feb 90 10:08:00 -0500
From:    <[e-mail]>
Subject: The ethics of virus eradication

I am posting the story of this incident to VIRUS-L in order to elicit
your comments. Has anyone run into a similar circumstance?

This week (Feb 5th-9th, 1990) marked the first occurrence of PC
computer viruses on our campus. First our Library received the census
disk, which we were warned of, and secondly a faculty member was
infected by Jerusalem B. I was able to clean-up this system with some
effort in about an hour. This was the last thing I did on Thursday
afternoon. On Friday, I posted mail to all campus mainframe account
holders (most of our campus users since our PC network is just in the
beginning phase) about the two incidents, and how to avoid virus
infections. In this E-mail message, I was particularly careful not to
mention the name or department of the faculty member involved.

Well, that didn't work. The faculty member was extremely angry about
the E-mail message. I did mention the type of program that was the
supposed virus vector. He contended that anyone on campus would figure
out his identity from the type of program (fractals), since he was
teaching a continuing course on the subject. I won't go into the
details of the venom that was directed my way.

My questions are these - what should I have done? Kept the infection
secret? Are computer viruses a Social Disease? Are we physicians who
are supposed to swear some form of Computerized Hippocratic Oath of
confidentiality? Or, do we paint a Scarlet-V on the heads(or
terminals) of those unfortunate ( careless enough) to become infected?
I would like to hear of similar experiences and policies enacted to
deal with virus infections.

[^^^^^]      [^^^^^]      [^^^^^]      [^^^^^]      [^^^^^]      [^^^^^]
[     ]______[     ]______[     ]______[     ]______[     ]______[     ]
[ Alan N. Federman, Computing and Data Processing, Indiana U.-Purdue U.]
[ 2101 Coliseum Blvd. E., Fort Wayne, IN 46805-1499                    ]
[ FEDERMAN@IPFWCVAX <- BITNET      [phone]                       ]
[----------------------------------------------------------------------]

------------------------------

Date:    Tue, 13 Feb 90 09:52:58 -0600
From:    James Ford <[e-mail]>
Subject: VSUM9002.ZIP (PC)

The following file has been added to MIBSRV.MIB.ENG.UA.EDU (130.160.20.80)
for access via anonymous FTP in the directory pub/ibm-antivirus.

VSUM9002.ZIP - Virus Information Summary List (February 03, 1990)
               Text file (ZIPed) of virii known.  Downloaded from
               Homebase on 02/09/90
- ----------
    James Ford - [e-mail], [e-mail]

[Ed. The unzipped version of this file, virussum.doc, is available on
cert.sei.cmu.edu (IP number 128.237.253.5) in pub/virus-l/docs.]

------------------------------

Date:    Tue, 13 Feb 90 12:43:00 -0500
From:    <[e-mail]>
Subject: Copyrights

It has been noted that the author of a virus has an implied copyright
on the work. However, this will only be of any significance if the
author enforces the copyright by suing anyone who distributes the source
code without permission. But -
   1. Is the copyright enforceable if the author cannot be located with
      a reasonable search?
   2. Who would claim ownership of a "released" virus? There might be
      a small benifit from suing over copyright infringement, but
      but the author would be sued for a much larger amount for
      writing the virus and releasing it.
Also, the benifits of distributing source code (so that anti-virals can
be written) would probably legally outweigh the copywrite ownership case.

------------------------------

Date:    13 Feb 90 00:00:00 +0000
From:    "David.M..Chess" <[e-mail]>
Subject: Many WDEF reports (Mac)

Curious as to why we're seeing all these WDEF reports, and not similar
numbers of reports of other widespread viruses.  Has it just become a
tradition to report WDEF on VIRUS-L, or is WDEF better at spreading?
If the latter, does anyone have a good feeling for what about WDEF
makes it so (um) virulent?  DC

------------------------------

Date:    13 Feb 90 17:40:35 +0000
From:    proton!spin![e-mail] (David Legg)
Subject: Re: The AIDS "Trojan" is a Copy Protection System

munnari!mqccsunc.mqcc.mq.oz.au![e-mail] (Ian Farquhar) writes:
>For several weeks we have been monitoring the discussion in comp.virus

Quote of license agreement, summary of warning in same, and the
conclusion that this is merely an elaborate copy protection scheme
deleted for brevity.

I too have been following the discussion, and while Mr. Farquhar
presents a some reasonable comments, I think he should consider the
following.

A. The disks were unsolicited material.
         In the US, that means the receiver owns them free and clear,
         no matter what "agreement", invoices or other demand for
         payment is made.  What is the australian (and other target
        countries) law in this regard.

B The "COPY PROTECTION" prevented all subsequent use of the entire
        computer system, but only after it had been executed.
        It would not prevent copying the master disks on an
        unaffected system, nor would it have prevented the execution
        of those copyied disks on other systems. Ususal copy protection
        either prevents copying the master, or makes the copies useless
        on other systems.

C For it to be "COPY PROTECTION" system, there must be something
        real to protect, I have not seen any mention of anyone
        finding any real programs or information on the disk.
         (The survey program I saw mentioned seemed to be more
         of a quick and dirty mockup than anything else.)

C This is not another instance of a program which will self-destruct
        if used in an unlicensed environment. It effectively destroyed
        the entire computer environment. As Mr. Farquhar states, this
        might have been a recoverable event, we dont know if PC Cyborg
        would have sent a fix-up disk in response to payment,
        this is extortion.

If PC Cyborg was really interested in leasing software about aids, there
are well established methods for advertising, making demo versions, etc.

The sophistication of the methods they employed demonstrates the level of
skill and knowledge they have.  The effects on the computer systems are
intentional, not the results of faults in the code as in the case of many
viruses.

The cost of mailing the disk was significant.

Therefore I think we can be sure that the authors knew exactly what they
were doing and expected a large financial return for thier efforts.

Disclaimer: These are my own opinions and not necessarily those of my
        employer.
Dave Legg                       |Internet: [e-mail]
Radiation Research Lab          |UUCP:  ...!ucrmath!proton!legg
Loma Linda University Medical Center
Loma Linda, CA 92354. [phone]

------------------------------

Date: 13 Feb 90 13:08:00 EST
From: "zmudzinski, thomas" <[e-mail]>
Subject: The AIDS "Trojan" is a Copy Protection System

In Virus-L V3 #38 Ian Farquhar writes:
...
> If the author of this program is convicted, it will be the first
> conviction ever for the hidious crime of writing a copy protection
> system, and will be one of the biggest farces of justice ever
> witnessed.

Zapping a hard disk and calling it copy protection is overkill.

One is generally not allowed to use lethal force to protect mere
property.  (You may kill in self-defense, and you may defend your
property, thereby making "self-defense" more likely, if that's
your karma.)  Rigging lethal deadfalls is a no-no (it's called
"reckless endangerment" and similar verbage).

Justice Holmes wrote that your right to swing your fist ends at
the tip of my nose.  The right to protect a person's intellectual
property must end when it damages another's physical property.

I consider most copy protection to be just that, a hidious crime.
If I can't make my own back-up copy of a program, I feel that the
vendor is responsible for providing me with a replacement when
the original disk fails.  Ideally this should be at no charge,
including the prepaid return-mailer that would hold the failed
disk -- and if we're talking about an applications package that
I've become dependent upon (choose any software you'd hate to be
without for 36 hours), I want damages!
                              ^^^^^^^
.................................................................
: Tom Zmudzinski   :    "In just causes, there are no failures, :
: DCS Data Systems : only delayed successes." - Robert Sheckley :
: McLean, VA       :    "Why do I feel overly successful?" - me :
:..................:............................................:

------------------------------

Date:    Tue, 13 Feb 90 10:55:42 -0800
From:    [e-mail]
Subject: Re: WDEF and AppleShare (Mac)

Peter W. Day writes:
> Re the discussion of infection of AppleShare servers by WDEF and
> whether to run GateKeeper there, and Brian Bechtel's point that the
> server does not use its desktop file, so the disktop file can be
> removed, after which the server can not be infected by WDEF.
>
> Even if you leave the file "desktop" on the server, that file is not
> seen by clients (even using programs that can see the desktop file on
> local disks), so it appears that there is no way a client can infect
> an AppleShare server with WDEF.

This is an incorrect conclusion.

If an AppleShare server publishes a disk which contains a Desktop file,
client systems CAN see the Desktop file.  If a client system is infected
by WDEF, it _will_ attempt to open and infect the Desktop file on the
server.  If the client was granted "Make changes" permission for the
volume itself, WDEF will be able to infect the Desktop file on the server
volume.  This infection-process causes the server's Desktop file to be
updated by the client's Resource Manager... it can generate a very large
amount of network activity, and "lock up" the client for an extended
period... 15-30 seconds is not unusual.  This performance-degradation
is one of the warning signs of a WDEF infection.  Trust me... this DOES
happen!

This infected Desktop file will not, however, be capable of infecting other
clients.  The Finder on a client machine does not attempt to open the
Desktop file on the server... instead, it uses AFP services to fetch
icons and bundle information from the AppleShare server (which uses
the Desktop Manager interface to retrieve them from the Desktop Manager
database files).

This doesn't mean that the infection is benign, though.  If you reboot
the server from a floppy (or other volume) which does not contain the
Desktop Manager INIT, the "latent" infection in the server's Desktop file
will become active.

>                                 Clearly you could do so by putting an
> infected diskette in the server when it was running as a workstation
> (e.g. by booting it using an infected diskette).  But could you infect
> the server by inserting an infected diskette in it while it was
> running as a server?

Yes.  An infected floppy could infect the Desktop file on the hard disk,
even if the Desktop Manager were running.  This is another way to create
a "latent" WDEF infection.

>                          Once infected, will the server infect local disks
> of clients?

Nope... as mentioned above, the Finders on the client machines do not
open the Desktop file on the server.

The best ways to ensure that your AppleShare servers do not become
infected (by clients, or otherwise) are:

1) Install a Desktop-scanning INIT, such as Gatekeeper Aid, Eradicat'Em,
   or an up-to-date version of one of the commercial antivirals.  This
   will ensure that infected floppies are cleansed when inserted, and that
   any infection which _does_ sneak in will be cleansed when you reboot.

2) Do NOT grant AppleShare clients the "Make changes" permission to the
   root directory on a published volume.  Make all changes to this
   directory from the server itself.  Grant "Make changes" permission
   only to lower-level directories.  This will ensure that an infected
   client is unable to update the Desktop file on your server's volume.

Remember that a Desktop file will be created on your volumes if you boot
from ANY disk which doesn't have the Desktop Manager INIT in its System
folder.  You should NOT simply install Desktop Manager, delete the old
Desktop file, and assume that you are safe from infection... this method
is not reliable!
- --
Dave Platt                                             VOICE: [phone]
  UUCP: ...!{ames,apple,uunet}!coherent!dplatt   DOMAIN: [e-mail]
  INTERNET:       coherent![e-mail],  [e-mail]
  USNAIL: Coherent Thought Inc.  3350 West Bayshore #205  Palo Alto CA 94303

------------------------------

Date:    13 Feb 90 19:50:21 +0000
From:    [e-mail] (Lambert Meertens)
Subject: Re: Re universal detectors.

[e-mail] (GEORGE SVETLICHNY) writes:
) I'm actually mixing mathematics and technology in the above. The purely
) mathematical conjecture would be (having defined "virus" in some
) appropriate useful way): There is a decidable set W such that 1) all
) programs containing viruses are in W and 2) all programs that do not
) contain viruses *have an equivalent* (identical input-output behaviour)
) that is not in W. Program equivalence is undecidable so this does not
) contradict the undecidability of virus detection. The technological
) part would consiuAof expressing W in some convenient way through
) hardware architecture.
)
) Is this plausible? Frankly, it doesn't sound so to me, but I wouldn't
) discard it off hand. It's the only hope I see of some general
) mathematical result being useful for anti-viral strategies, so maybe we
) should look at it more closely.

To make this amenable to mathematical analysis, we need a precise
definition of "virus", of course, but I think that even without such a
definition there is an argument that makes it plausible that this *is*
in fact mathematically possible.

The argument assumes that we have at least a decidable after-the-fact test
that determines whether a program displayed, in its actual behaviour during
a given run, undesirable (virus-like) behaviour (whether by a bug or by
malicious intent of its author).

(N.B.  I don't know if we can give a useful formal definition of what
constitutes undesirable behaviour, but if we cannot capture this notion,
then any hope of creating a universal virus detector is vain.)

Moreover, it assumes (typical mathematical assumption) that we have
unlimited storage.

Given a program P, we can create another program P' which works as
follows (sketch only):

1.  Make a copy of the store.

2.  Operate like P, without touching the copy.

3.  On termination of P, determine whether undesirable behaviour occurred.

4.  If so, restore the store from the copy and flash a red light;
    otherwise, erase the copy and display a green light.
    (There could be an option to have a bell rung instead of the red
    light:-)

(In case the program does not terminate, we can press an abort button
whereupon the store is restored as well.)

The point is that there is a computable function F such that F(P) = P' with
the above characteristics, such that the range of F is a recursive set.
(The argument that F is a recursive function is simply that it is obvious
how to write a program for it.  That the range is recursive follows from
the fact that we can easily construct F such that larger input -- in some
suitable ordering -- gives rise to larger output, so to test if Y is in the
range of F we can enumerate the domain of F until we find an X such that
|F(X)| >= |Y|.)  Take the set W to be the complement of the range of F.
All benign programs have an equivalent program in W-complement, since F
does not change their input-output behaviour, and all programs in W-
complement are by their construction harmless.

I do not see how this theoretical construction would have much relevance,
but it is amusing to realise that the gist of it is to make a full backup
before you run a non-trusted program, which is indeed a good thing.  Now if
only we could timely detect that infection did occur, then it would be easy
to restore and stop the spreading.

- --Lambert Meertens, CWI, Amsterdam; [e-mail]

------------------------------

Date:    Tue, 13 Feb 90 17:08:07 +0200
From:    Y. Radai <[e-mail]>
Subject: Re: Signature Programs

  There have been a few responses to my postings on signature (or
checksum) programs and algorithms in V2 #256 and V3 #4, resp., mainly
by Bob Bosen.  Let me begin by briefly summarizing my earlier postings:

  In the first posting I pointed out that what has to ensure security
on a computer is not simply an algorithm, but rather a *program* which
implements it in a given operating system.  And even a program based
on the most sophisticated checksum algorithm in the world is circum-
ventable if it is not written very carefully, since there are liable
to be (and in PC-DOS/MS-DOS definitely *are*) loopholes in the system
which are independent of the checksum algorithm and which a virus
writer could exploit.
  Bob Bosen responded to this point only by saying that in the compa-
rison of algorithms, both implementing programs must be well-written
and convenient and "apply the algorithm across all program code
without exception".  Well, that last phrase may suggest to some people
that it's necessary to checksum the boot sector and partition record
also, but otherwise, this requirement is insufficient, at least as I
understand Bob's words.  And even if we interpret it in such a broad
manner that it becomes theoretically correct, this rule is rather
useless; it gives the checksum-program writer no clue whatsoever as
to how to plug most of the loopholes.

  I considered, and still consider, this emphasis on the implementing
program, rather than on the algorithm, to be fully justified.  One
way of putting it is that given a choice between a sophisticated algo-
algorithm with poor implementation and a mediocre algorithm with good
implementation, I would prefer the latter.
  Of course, it's not really an either-or matter; there's nothing to
prevent us from striving for quality in *both* aspects.  And as long
as one is aware that a naive implementation of an algorithm is very
dangerous, and is aware of the great difficulty of conceiving of all
of the loopholes, I suppose it makes sense to ask which of several
algorithms is best, given the *assumption* that all are implemented
equally well.  So in my later posting, I suspended discussion of im-
plementation and restricted myself to algorithms.  I mentioned six of
them and expressed the opinion that for anti-viral purposes (which I
characterized by three properties but there are actually more), any
algorithm which satisfied a certain pair of conditions should be suf-
ficiently secure.  I considered the best algorithm to be the fastest
of those satisfying these two conditions, my guess being that this
would be CRC.  However, I specifically mentioned three points on which
I might be wrong.  I concluded by challenging people to supply evi-
dence and argumentation relative to the viral environment.

  Bob Bosen took up my challenge as far as argumentation is involved:
>             Specifically, in his opinion (1), Mr. Radai says that a
>virus must perform all its work ... "on the computer which it's attacking
>and in a very short time". That is not necessarily true. In networked
>environments with shared file systems, (and especially if remote
>execution is available), viruses could execute on different computers and
>take as much time as they needed. Also, as pointed out by Bill Murray,
>viral infections during the process of software distribution may be done
>off-line at the convenience of the attackers.

  But as Bill correctly pointed out, we have in mind two different ap-
plications of authentication software: (I) for recognizing contamina-
tion of the program in the target execution environment; (II) for en-
suring that programs are received as they are shipped.  (II) is un-
doubtedly important, but my articles were concerned only with (I)
(sorry I didn't state this explicitly), hence Bob's reference to in-
fection during software distribution is not relevant to my remarks.
  As for networked environments, he's right, there are *some* such
environments in which property (1) would not hold.  However, the
average user does *not* operate in such an environment.  Why should
*he* choose a slow program just because it adds security in *such* an
environment?

>I must also disagree with Mr. Radai's opinion (2), wherein he posits "By
>its very nature, a virus is designed to attack a large percentage of the
>users of a particular system." Why? What's to prevent a virus writer from
>launching a "surgical strike" against a small population of familiar
>computers that are known to control assets or information of great value?

I must say I find this response rather surprising, considering that
the answer to your question is contained in the continuation of the
very same paragraph from which you're quoting me.  In case it wasn't
clear, I'll rephrase that answer:  There's nothing at all to prevent
such a strike, but if such a strike is made, there's no reason why it
has to be a *viral* strike.  The great advantage of writing a virus,
as compared to an ordinary immediate-acting Trojan horse (which I'll
abbreviate here to simply "a Trojan") is that by delaying its damag-
ing effects and replicating itself, it can spread rapidly to a large
population of users and thus ultimately cause damage to many more
users.  But it has the disadvantage that the delay of damage gives
checksum programs a chance to detect the infection.  Now if you're
talking about performing damage to only a *small* population, then
there's not much advantage to writing a virus rather than a Trojan.
A Trojan is easier to write and can't be detected by a checksum pro-
gram.  So to your question of what's to prevent a viral strike against
a small population, I counterpose the question What's to prevent a
*Trojan* attack against a small population?  What could your sophisti-
cated algorithm do against that??  The answer is Nothing.  Even ISO
8731-2 raised to the X9.9-th power would be helpless against an imme-
diate-acting Trojan.

>As to Mr. Radai's opinion (3), he says that "a virus writer is not in a
>position to know what checksum algorithms may be in use on the computers
>on which his virus is unleashed." That's true TODAY. ....
>                                              .... But if our society is
>ever going to overcome its current vulnerability, we'll need reliable,
>low-cost defense mechanisms that are worthy of widespread use. This
>implies a necessity for economies of scale. Therefore, this opinion (3)
>will not necessarily be true for very long.

  I appreciate this looking to the future (which is why I mentioned
loopholes which have not yet been exploited in any existing virus).
However, I'm less enthusiastic about this particular point.  I presume
that when Bob talks of the need for "reliable low-cost mechanisms" and
"economies of scale" he is referring to his previously expressed opin-
ion that someday there may be only a few high-quality programs used
by millions of people.  Frankly, I find the "few" part of this rather
unlikely.  If anything, the trend seems to be in the opposite direc-
tion.  (For example, there's a new algorithm MD4 which has been de-
scribed by Ronald Rivest.)  And even if the situation envisioned by
Bob should someday arise, I think it would still be quite difficult to
exploit.

  In any case, properties (2) and (3) were less important to my case
than (1).  And there's an important fourth property of the environ-
ment which I neglected to mention.  Almost all types of attacks pro-
posed by cryptanalysts against signature algorithms involve *knowledge
of the signature* of one or more files, which is natural in Applica-
tion (II).  It therefore requires a very secure algorithm.  But in the
environment I am considering (Application (I)), such knowledge and
hence such attacks are impossible even with an unsophisticated algo-
rithm such as CRC, provided different users use different keys, and
the checksum base etc. are kept offline while a virus may be in memory.

>                                                          From what I've
>read in this forum of late, it does appear that Ross Greenberg and Y.
>Radai are at one end of this spectrum and that Bill Murray, Ralph Merkle,
>Jim Bidzos, Fred Cohen, and the others mentioned in Mr. Radai's Jan. 4
>posting are more or less at the other end with me. (If I've
>misrepresented your views here, gentlemen, I hope you'll forgive and
>correct me for it. I'm reading between the lines.)

First, don't forget that the "others" mentioned in my posting include
Prof. Michael Rabin, and that the algorithm which he advocated was the
same, relatively unsophisticated, algorithm which I consider (tenta-
tively) to be the best.  (I take this opportunity to point out that
the algorithm of Rabin's to which I am referring is from a little-
known paper of his, and is not to be confused with a better-known
algorithm of his which involves taking the square root of the message
[= the file] modulo the product of two secret primes.)
  As concerns your lumping me together with Ross Greenberg at the low
end of the sophistication spectrum, that picture is not far from cor-
rect only if you limit yourself to the *algorithm* involved.  As re-
gards security of the *implementing program*, I'm miles away from Ross.


  Although I have said that I tentatively consider CRC to be the best
algorithm for the purposes which I am considering, I wish to empha-
size that I am in no way committed to it.  If someone can produce
evidence that some other algorithm is both more secure in the environ-
ment with which I am concerned and is faster or almost as fast as CRC,
I'm willing to alter my opinion.  However, what it takes to convince
me (and I think a lot of other readers) is not a proclamation that
Committee X has adopted Algorithm Y as its standard, but *an actual
comparison of programs which implement the various algorithms*.
  In comparing speed, we will, of course, take into account what Bob
has pointed out, namely that a program can be written to implement a
sophisticated algorithm on a small part of the file and a fast algo-
rithm on the rest.  Obviously, such "hybrids" could also be among the
contenders.
  Comparing security is much trickier since the results will depend
strongly on what test viruses we can think of.  So no such test can
ever be conclusive.  But it should be more convincing than mere proc-
lamations and appeals to the authority of some committee or other.
(By the way, I made a challenge to compare the security of programs by
such tests over a month ago; why no response?)
  It is only when we have the results of such comparisons that each
user will be in a position to decide which program is best suited to
his needs.  My guess is that for Application (I) there won't be many
users who will choose a program which is based on a sophisticated
algorithm.

                                     Y. Radai
                                     Hebrew Univ. of Jerusalem, Israel
                                     [e-mail]

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Wednesday, 14 Feb 1990    Volume 3 : Issue 41

Today's Topics:

Introduction to the VIRUS-L Index
VIRUS-L Index IBM PC Topics
VIRUS-L Index Macintosh Topics
VIRUS-L Index Miscellaneous Topics

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

---------------------------------------------------------------------------

Date:    Tue, 13 Feb 90 11:17:49 -0500
From:    [e-mail]
Subject: Introduction to the VIRUS-L Index

This posting is the introduction to the VIRUS-L Index.  Hopefully
these indexes will be helpful to all.  I've only been able to index
the digests from January 1, 1990 as of yet, and still I am about a
week or two behind.  Should I ever catch up, I will begin to index
back-digests.

I plan to send out about one of these every month or so, and I
would guess that after 3 or so months I will have to start anew, for
the index will get too lengthy.  Any suggestions in that area will be
greatly appreciated.

The index's topics are my own personal views on the content of each
article; I have tried to sum up the contents of each in one line.  In
the cases that either the topic or the general heading does not point
to a specific article's subject line from the digest, I have included
the subject line in square brackets.

Karen Pichnarczyk
[e-mail]

[Ed. Thanks for providing this great service, Karyn!  I hope that the
index helps everyone out in going through back issues.  I'll maintain
a copy of the index for anonymous FTP on cert.sei.cmu.edu, in
pub/virus-l/archives.  Feedback on format etc. is appreciated and can
be sent to Karyn and/or to myself.]

------------------------------

Date:    Tue, 13 Feb 90 11:18:39 -0500
From:    [e-mail]
Subject: VIRUS-L Index IBM PC Topics

The following is an index of the VIRUS-L Digest involving IBM PC topics
of 1990 (Volume 3).  They are referenced by Digest number.  I have
included a short description of what the article is about, and in the
cases that the description does not match the article's subject line,
I have placed the subject line in square brackets.

                           VIRUS-L Index for V3

Compiled by:  Karen Pichnarczyk
              [e-mail]

Last updated: February 12, 1990
Contains V3 1 through V3 28  (January 2, 1990 - January 31, 1990)

Virus Alerts
  The Desktop Fractal Design System contains a virus  (1813 virus)
                               [Fractal Virus Alert]                   9
  Maybe not all copies of Desktop Fractal Design are infected
                               [re: Virus scanning]                   11

  Driver Disk shipped with a Wise Data Systems PC has Stoned virus    10
  Possible virus warning - text strings contain copyright messages
               for Compac Computer Corp                               14
  Orig. msg false-Desktop Fractal Design (his orig copy not
                                       contaminated)                  22
  US Gov't printing office Census disk has Jerusalem B
                                  [library virus]                     26

*************************************************************************

                      PC Virus Protection Programs

FPROT
  List of viruses it finds and description                             7
  Clarification - desc + list of viruses it checks for                11
  2 minor bugs to be fixed in next release [Requests/Questions]       19
  Devil's Dance virus FPROT string to detect it [three new viruses]   24

Flushot +
  has fast checksum checker [VIRUS-L Digest V3 #4]                     5
  Comment on its checksums - answer to above
                       [The Checksum feature of Flushot+]             27

PCData
  Free utility from PC Magazine                                       25
  Uploaded to SIMTEL 20                                               27

Virus Buster
  Virus Buster 1.10 has a bug (description)                            2

Viruscan/CLEAN/SCANRES
  SCANV53 has a bug, therefore SCANV54 corrects it [SCANV54]           3
  John McAfee describes SCANV53 problem                                5
  SCANV55 has been released (short desc) [SCANV55 and CLEANV55]        8
  Which BBS has SCANV55 and CleanV55?                                  9
  Can you get SCANxx.ARC as an AFD?                                   12
  CLEAN doesn't make checksum same as before Jerusalem B infection    21

Hard Drive Overlord
  Request for info - he heard it was similar to Mac's Gatekeeper      15

General Anti-viral info
  What's recommended to use against viruses, where do I get it, etc   26

*************************************************************************

                                PC Viruses

1260 virus
  Descr - can't use ordinary ID strings to detect it, encryption
                     Cascade virus [three new viruses]                24
  Descr - uses encryption  [4096 and 1260 viruses]                    27
  other viruses that have identical startup code: Syslock, Macho,
                                        Advent viruses                27

1813 virus  (see also Jerusalem virus)
  The Desktop Fractal Design System contains a virus
                               [Fractal Virus Alert]                   9
  How do I get rid of it?  [Desktop Fractal Design System]            10
  IBM's VIRSCAN identified it as 1813 (desc) [1812]                   10
  1813 is the Jerusalem virus                                         11
  The Desktop Fractal Design System manufacturer sent a letter
      to all registered users [Academic Press makes good!]            15
  2 articles explain what the virus does and a program to fight
       it [fractal disk infection]                                    15
  Some books get recalled too [re: Academic Press makes good!]        17
  One of Desktop Fract. Design orig thought was a virus WASN'T        22
  Public Reply - defending that at least 1 copy was not infected      24
  Which copy was infected?                                            24

4096 virus
  Descr-few public reports, but its virtually invisible
                              [4096 & 1260 viruses]                   27

8290
  from India / request for info  [8290 & Happy Birthday Jossie]        4

Advent virus
  Has similar startup code to 1260, Syslock, Macho [re: 1260 virus]   27

AIDS trojan
  Does AIDS encrypt then modify encrypt key? (Contains McAfee's
    statement about the trojan) [re: AIDS Trojan Research]             1
  Response to SWE's encryption claim (DES, DEA)
           [comments attributed to SWE]                                1
  Discussion on AIDS - a reader's opinion [AIDS Program]               1
  Only 1 company in Iceland got it  [AIDS note]                        4
  How much damage was done total?                                     10
  This is not the virus [There is more than 1 virus called AIDS!]     21

AIDS virus
  This is not the trojan [There is more than 1 virus called AIDS!]    21

Alabama
  Short comment  [4096 and 1260 viruses]                              27

Amstrad Virus
  Description of this virus  [New Viruses]                             3
  It does have something to do with Amstrad computers / contains
      name of a respected professor in Portugal                        6

DBASE Virus
  Case History of one infection  [Two Serious Cases]                   3

December 24 virus
  New one; displaying "Gledileg Jol"                                   2
  It's a variant of Icelandic Virus, some details                      2
  Description / short, variant of Icelandic  [New Viruses]             3

Devil's Dance
  Quick descr, w/ FPROT string to detect it [three new viruses]       24

Disk Killer / Ogre virus
  Request for help                                                     4

Eddie (Dark Avenger, V651)
  V651 is called Eddie-2, uses some of same techniques [V651 virus]   24

Happy Birthday Jossie Virus
  from India / request for info  [8290 & Happy Birthday Jossie]        4

Icelandic / Saratoga
  Case History of an infection  [Two Serious Cases]                    3
  December 24th is a variant of Icelandic-2  [New Viruses]             3

Israeli Boot Virus
  Other Names: "Falling Letters Boot Virus" and
        "the Swapping Virus"  [re: the missing viruses]                4

Jerusalem   (see also 1813 virus)
  How do I get rid of it without deleting programs?                    6
  Where to get Jerusalem B virus remover                               7
  What does it do/CLEAN 55 doesn't appear perfect                     21
  Found Jerusalem A - what does this do - How to get rid of it???     22
  US Gov't printing office Census disk has Jer. B [library virus]     26
  Confirmation/copy of letter they're sending out re: virus
                   [confirmation on library disk infection]           26

Macho virus
  has similar startup code to 1260, Syslock, Advent [re: 1260 virus]  27

Musician / Oropax Virus
  Its the same as Oropax from West Germany  [New Viruses]              3

Nuclear War Trojan/virus
  Has anyone heard of this? (short descr of possible trojan/virus)
                          [Posssible new virus?? NUCLEUR war]         25
  Check autoexec to see if someone just typed the msg
                           [re: Thermal Nuclear War?]                 27
  Not a virus at all   [Possible new virus followup]                  27

Pakistani Brain Virus
  How do you eliminate Pakistan C-Brain virus?                        14

Payday Virus
  Yet another variant of the Jerusalem virus  [New Viruses]            3

Perfume (765 or "4711")
  Description / it asks a question which 4711 is the answer
                                            [New Viruses]              3

Ping Pong
  found Ping Pong and Ping Pong B [Virus info Request]                23

Stoned Virus
  Stoned Virus Killer - how to get rid of the Stoned Virus             2
  History of creation and first usage [Re: viruses Rhyme and Reason]   6
  Driver Disk shipped with a Wise Data Systems PC has Stoned virus    10
  What's the impact of the "Stoned" virus?                            20
  found in LRS lab at Univ. of Guelph - what does it do/disinfectors  22
  found in his dept [virus info request]                              23
  Where to find info  6 places w/info on "Stoned"                     24

Syslock virus
  has similar startup code to 1260, Macho, Advent [re: 1260 virus]    27

V651 virus (see Eddie-2)
  full Descr incl errors made by author                               24

Vcomm
  Description / from Poland  [New Viruses]                             3

Vienna Virus  (also: VHP-648, Austrian)
  Oregon State University used M-Vienna to remove it                  13
  V651 virus similar to VHP-648 (Vienna, Austrian) [V651 virus]       24

Virus101
  "Big Brother" of virus90, descr, [Three new viruses]                24
  short comment  [4096 & 1260 viruses]                                27

W13
  Description / with two variants known  [New Viruses]                 3
  Can anyone translate text found? [Requests/Questions]               19
  Polish translation  [W13 Polish text]                               23

Yankee Doodle virus
  Request for info and a disinfectant program                          2
  Plays song at 5 pm, is memory resident [the Yankee virus]           21
  GWU infected - what to do?                                          25

Yankee virus
  Descr, NOT Yankee Doodle virus, plays every infection               21

Zero Bug Virus  (also Palette)
  Also called 1536 or Palette virus [re: the missing viruses]          4
  Can anyone confirm it is 1538 bytes? thinks it may be Zero Bug
                                  [Requests/Questions]                19
  1538 might have been a typo - Palette IS zero bug
                              [Re: Requests/Questions]                20

------------------------------

Date:    Tue, 13 Feb 90 11:19:09 -0500
From:    [e-mail]
Subject: VIRUS-L Index Macintosh Topics

The following is an index of the VIRUS-L Digests involving Macintosh
topicsof 1990 (Volume 3). They are referenced by Digest number.  I have
included a short description of what the article is about, and in the
cases that the description does not match the article's subject line,
I have placed the subject line in square brackets.

                           VIRUS-L Index for V3

Compiled by:  Karen Pichnarczyk
              [e-mail]

Last updated: February 12, 1990
Contains V3 1 through V3 28  (January 2, 1990 - January 31, 1990)


Virus Alerts
  after trying JCremote and MacII Diagnostic Sound, got a
                 damaged resource fork.                               11
  Grammitik may contain WDEF A                                        19
  New NVIR like virus, VIREX can detect, can't identify or fix;
         Disinfectant can't find  [New virus?]                        23

*************************************************************************

Anti-Virals
  How to get Mac Anti-viral programs                                   4
  Another place to get them  [RE: Anti-virus programs]                 4
  Is this Anti-viral site available to Usenet as well as Bitnet?       6
  Is there alternate virus protection besides Vaccine & Gatekeeper?    6
  answer to alt. virus prot:  try RWATCHER  [RE: Alt. virus prot.]     7
  Eradicat'Em - place to get it (cures WDEF)   [WDEF]                  9
  1st Aid Software, Publisher of Anti-virus Kit, will do no further
                updates to s/w  [An unfortunate victim]               11

Disinfectant
  When Disinfectant is used, gets Gatekeeper violation                 5
  Want Disinfectant to use clone names too                            21
  There is NO version 1.6 yet! [Disinfectant versions]                22
  Disinfectant 1.6 has been released - descr                          27

Eradicat'Em
  Eradicat'Em - place to get it (cures WDEF)   [WDEF]                  9
  The Eradicat'Em init may be unstable - looking for proof            19
  Eradication! was unstable, good long descr of Eradicat'Em           20

Gatekeeper
       (see also "Implied Loader Virus")
  Where to get info on it?                                             3
  Possible problem with Gatekeeper Aid INIT and Finder - request
     for help  [Gatekeeper Aid Question]                               3
  Gatekeeper Aid 1.0.1 fixes Finder Bug [re: Gatekeeper Problems]      4
  When Disinfectant is used, gets Gatekeeper violation                 5
  How do you configure Gatekeeper with a Dest Scanner?                 6
  Gatekeeper Aid found a virus - user never heard of it
                   [Implied Loader 'Pack' virus]                       6
  Answer to implied Loader virus: Look for invisible file "PIC"        7
  Infection [RE: Questioning ethics at computing sites]                9
  something virus-like: Adobe Separator 20 (ADBS)
                [Gatekeeper veto: Normal Behavior or virus attack?]   27

General Topics
  How do you check for viruses if they have been Binhexed or used
    Stuffit?   [Disinfecting Binhexed Files]                           3

Implied Loader Virus
  Gatekeeper Aid found a virus - user never heard of it
                   [Implied Loader 'Pack' virus]                       6
  Answer to implied Loader virus: Look for invisible file "PIC"        7
  Brings up dangerous consequences                                    10
  some more comments - [Implied Loading and Accidental Destruction]   11

SAM
  SAM 1.4 found WDEF A [WDEF A infection followup]                    19

Scores
  Univ of Oregon has it sometimes                                     20
  Sometimes Univ Nebraska Omaha gets it [re: WDEF at U of Oregon]     23

VIREX
  VIREX can catch it, but most VIREX users don't use that option
                                [re: Apology to Mainstay Software]     3

VIRUS DETECTIVE
  descr. of odd behaviou of Virus Detective 3.0.1
       [WDEF & Virus Detective 3.0.1]                                 11

VIRUSREM
  Problem: some nodes refuse parts - [Partial VIRUSREM Package]        7

Viruses in Public Labs
  Viruses that have hit this lab - discussion                          3

WDEF
  Programs that catch/remove WDEF [Apology to Mainstay Software]       1
  VIREX can catch it, but most VIREX users don't use that option
                                [re: Apology to Mainstay Software]     3
  Eradicat'Em kills it  [WDEF]                                         9
  descr. of odd behaviou of Virus Detective 3.0.1
       [WDEF & Virus Detective 3.0.1]                                 11
  Grammatik may have WDEF A infecting it                              19
  Grammatik was infected - SAM 1.4 found it                           19
  Please supply info on what WDEF does [RE: WDEF at U of Oregon]      21
  WDEF propagates using data files [virus propogation in
                                    non-executible files]             27

WDEF sightings
  Another infection [WDEF A]                                           8
  Infection [RE: Questioning ethics at computing sites]                9
  found in Miami University in Oxford, Ohio                           11
  found in Trinity College, Dublin, Ireland                           11
  found in U. of North Carolian at Chapel Hill                        13
  found in Arizona State Univ - what was done to remove it            13
  found at Univ. of Oregon, also found NVIR A&B, jerusalem, PingPong  15
  found at Univ of Manitoba - Winnipeg, Canada                        19
  found at Univ of Oregon in 10 machines                              20
  found at Clemson Univ                                               22
  found at Cambridge 22 Jan                                           23
  found at Univ of Nebrasks Omaha                                     23
  found at Washington State Univ.                                     23
  twice found at a national copy center chain, also a univ bookstore
                                            [WDEF in public places]   23
  found at Humboldt State U, CA.                                      24
  found at Univ. of South Carolina                                    25
  WDEF B found at Univ of Rochester                                   25
  Found at Univ of Central Florida                                    25
  WDEF A found at Connecticut college                                 27
  WDEF A found at Univ. of Miami                                      27

------------------------------

Date:    Tue, 13 Feb 90 11:21:07 -0500
From:    [e-mail]
Subject: VIRUS-L Index Miscellaneous Topics

The following is an index of the VIRUS-L Digests involving topics other
than Macintosh or IBM PC of 1990 (Volume 3).  They are referenced by
Digest number.  I have included a short description of what the article
is about, and in the cases that the description does not match the
article's subject line, I have placed the subject line in square brackets.

                           VIRUS-L Index for V3

Compiled by:  Karen Pichnarczyk
              [e-mail]

Last updated: February 12, 1990
Contains V3 1 through V3 28   (January 2, 1990 - January 31, 1990)

                   Anti-Viral Archives for all computers

   Latest copy                                                         5
   Introduction to anti-viral archives                                28
   Latest copy  (January 31, 1990)                                    28

*************************************************************************

Files to Download
  Directions how to FTP from BITNET [Bitnet *can* FTP now]            16
  Files added to MIBSRV.MIB.ENG.UA.EDU  [New files]                   16
  Bitnet files now on SIMTEL-20                                       19
  Files added to MIBSRV                                               26

Uploads to SIMTEL20:
  Uploaded Dirty Dozen List #9C to MSDOS.TROJAN.PRO                    2
  SCANV54 has been uploaded                                            8
  SCANV55 & CLEANP55 uploaded                                         15
  SCANV56, et al - uploaded                                           17
  BITNET files on SIMTEL20                                            19
  PCData files (from PC Magazine) have been uploaded                  27

*************************************************************************

                           VAX Topics (VAX/VMS)

Possible virus?
  Is there a virus on VAX? [UNCONFIRMED virus on Vax]                 19
  Response: person is a potential virus author [re: virus request]    23
  Comment: yes, we should track potential virus authors
                         [security and Internet Worms]                25
  Requestor of virus info (V3 #19) may lose access to UMNEWS/UMBB
                             Policy  [VAX virus request and UMNEWS]   25
  Thinks orig. requestor was a user, not potential writer/comment
                                     on Bill of Rights                25
  Thinks originator committed an English language blunder
                     [re: "Virus request" from Taiwan]                25
  Comment: people should be able to responsibly give virus code to
                           people  [re: virus request]                26

*************************************************************************

                               AMIGA topics

VIRUSX
  Correction: a version may be a trojan - discussion                   1

XENO virus
  Help! I'm hit - what do I do?  desc of virus and infection          13

*************************************************************************

                               Atari topics

  Does anyone know of a virus that causes a head crash?                9

*************************************************************************

                              Network Topics

  Some viruses can spread over a network - how they do it
      [Network Server Infections]                                      2

*************************************************************************

                      Discussions and Points of View

Bank ATM cards   (see also Morris Trial)
  Phone-in-credit-purchase industry/ATM cards you tell bank your
                   password (PIN)  [re: Trial & Double Standard]      23
  The PW is not stored on the card                                    26

Book Reviews
  Review of "The Cuckoo's Egg"                                         3
  Review/overview of "Computer Viruses: Dealing w/Electronic
                 Vandalism & Programmed Threats" [ADAPSO virus book]  25
  Saw a good review of the "Cuckoo's Egg" in Smithsonian Mag
                                       [Article on Cliff Stoll]       25
  Comment on misprint in Review   [re: ADAPSO virus book]             27

Biological vs computer viruses
  General Discussion   [virus data collection]                         3
  A biologist speaks on the subject [virus biological analogy]         4
  Request for references on this topic
          [Biological analogy source requested]                       12
  Reference given [Re: Biological references requested]               13
  LP's have >1 groove-example given [re: practical a-priori viruscan] 23

Checksum Algorithm Discussion (see Signature Programs)
  Discussion of various authentication/signature/checksum algorithms   4
  Answer    [Uses of Macs against Viruses]                             5
  Another Answer (comment on Flushot+) [VIRUS-L Digest V3 #4]          5
  Further Discussion of RSA, etc.                                      6
  Questions to ponder                                                  8
  Comments on Checksums in general, using Flushot+ as an example
                         [the checksum feature of FLU_SHOT+]          27

Computer Ethics
  Discussion on ethics of not informing users that a virus is
     present on public computers in general usage                      6
  Advice [RE: Questioning ethics at computing sites]                   7
  The univ was not ignoring it (explanation of action taken)
                   [RE: Questioning ethics at computing sites]         9
  Guidelines to reduce chance of propogating viruses
         [Organizational attitudes about virus protection]            11
  An ethical code like medical code should apply to programmers       15
  What is appropriate punishment [re: ethical judgement on the worm]  16
  Moral/ethical comments (long)                                       17
  Dispute the article in ethics                                       18
  comment on societial norms vs normal computing practices (long)
                                   [Trial and Double Standard]        22
  Professional responsibility where merchant doesn't remedy
                  situation?   [WDEF in Public Places]                23
  What they do to protect a "public" MAC
                              [Public PC lab responsibility]          26

Conferences
  Call for Papers - 13th Nat. Computer Security Conference (long)      1
  Call for speakers - MIS 10th Annual Conference on Control,
         Audit & Security of IBM Systems                               9

DES
  Helsinki Univ. has a separate implementation that can be
     anonymous FTP'd    [re: DES Availability]                         1
  Discussion on DES/DEA; reply to letter submitted by SWE - cracking
     DES is harder than SWE says   [Comments Attributed to SWE]        1
  A W. German DES is available named PC-DES                            4

Morris Trial
  Jurors selected who had no computer knowledge                       12
  comment on non-technical jurors                                     13
  an article [New York Times on the Morris trial]                     14
  it is fair to use non-techie jurors                                 14
  more comments on jurors                                             14
  someone's experience as a juror                                     14
  enjoy hearing about the trial on VIRUS-L                            15
  I've been on jury duty                                              15
  An ethical code like medical code should apply to programmers       15
  in defense of computer literate juries                              16
  more comments                                                       16
  news of the trial - convict him!                                    16
  What is appropriate punishment [re: ethical judgement on the worm]  16
  Lawyers want people without education on a jury                     17
  From a witness - views on the jury                                  17
  Fact is- he did release the worm                                    17
  Fed. law for punishment/can't stop him from getting a computer job  17
  Moral/ethical comments (long)                                       17
  comment on hiring Morris                                            17
  (All articles in #18 are on this topic)
  Anything in trial supports the >1 author concept?                   18
  This forum says guilty!                                             18
  Comments on jury and irresponsibility of Morris                     18
  Morris infected AT&T Bell in high school                            18
  Dispute the article in ethics                                       18
  Give him "public service in the field of computing"???              18
  In defense of educated unemployed, homemakers&retired people        18
  the verdict                                                         18
  Correction/comment on judge, sentencing is Feb. 27                  19
  Comment on AT&T breakin - [Morris hacking Incidents]                20
  What judicial process said he released the worm (disputes V3 #17)
                                         [Innocent until proven...]   20
  factually guilty vs legally guilty                                  21
  Excerpts from an AP article  [Morris found guilty]                  21
  Morris had testified he did it.                                     21
  Nothing in trial supports >1 person BUT Morris didn't write the
                            password cracking code                    22
  comment on societial norms vs normal computing practices (long)
                                   [Trial and Double Standard]        22
  Why didn't Morris try to help the Internet group stop it?           23
  Phone-in-credit-purchase industry/ATM cards you tell bank your
                   password (PIN)  [re: Trial & Double Standard]      23
  How do I get a copy of Spafford's report?                           24
  Morris did try to stop worm, but was too late                       25
  according to papers, morris conceded he WAS responsible for
                  worm  [re: innocent until...]                       26

Shrink-wrap Software
  How to copyright shrink-wrap software / legalities
         [re: shrink-wrap Licenses]                                    4
  I thought shrink wrapped s/w was safe?!                              9
  3 steps to safe s/w                                                 10
  Retailers can re-shrinkwrap s/w                                     10
  Retailers perhaps use tamper-resistant packaging like Tylenol?      11
  Get in habit of scanning everything - stores re-wrap and
         commercial distributers sometimes have viruses               11
  Stores don't do virus checks on returned S/W (case history)         11
  Retailers have a "Trial/Return" policy for S/W                      11
  Vendors can sell s/w on write-protected diskettes                   12
  Steps a vendor can take to make sure returned s/w is virus-free     12
  Some vendors do sell s/w on write-protected diskettes               12
  Comment on vendor sell write-prot. s/w [Protecting s/w
                        from contamination]                           12
  In the UK they rarely see shrink-wrap; retailer won't demo          12
  Someone determined can write on a write-protected disk              13
  Most software comes write-enabled                                   13
  Most infections are by the well-intentioned                         14
  You do want to deal with retailers with a return policy             14
  Answer from someone who works in a store [re: some more thoughts
                            on shrink-wrapped software]               14
  Suggest that vendors w/ write prot. disks note that fact on disk    14
  Stores can *simply* do a sector-by-sector, byte-by-byte compare
                     of returned software                             15
  Why not just run a good virus checker?                              15
  If someone really wanted to infect a write-prot. disk, they could   15
  Dispute V3 #15 (*simply*)                                           20
  Trivial to tweak a drive to think a disk is writable - S/W not
                              factory write-protected                 21
  If S/W is returned, store ships disks to vendor, vendor ships
                                     clean disks to store             24

Signature Programs
  glad to hear people are concerned                                   22
  detailed dispute to RADAI'S comments                                22
  Analysis found useful                                               22
  Brief summary of Bosen's opinions                                   22
  Where get descr of ISO 8731-2?                                      24
  It takes more time to do then is acceptible (long)                  24
  Sophistated algorithms are NOT inherently superior to less soph.    24
  Clearing up misconceptions                                          26

Spafford's Theorems
  Comment on general viral information                                 1
  more comments                                                        3
  more  [WHM on Spafford's theorems]                                   4
  comment                                                              4
  Dispute V3 #1  [RE: comment by William Hugh Murray]                  6
  More discussion of V3 #1  [RE: Spafford's Theorems]                  6
  Another reply to WHMurray                                            6
  A comment on the Dispute [public trust vs viruses]                   7
  Another comment on the Dispute [Virus Scare & Backups]               7

Virus Trends (also: Faxes on PC's)
  Correction on topic that a version of VIRUSX may be a trojan         1
  New attack methods - text files, mail, postscript, fax, C++          3
  more opinions                                                        3
  a short comment                                                      4
  PC Fax Boards have async & bisync modem capability                   5
  Discussion of how PC Fax boards can transmit viruses                 6
  Concievable to embed a virus in a postscript font; also, VIDEO
       cyphers are viruses of a sort                                   6
  What FAXes on PC's can do                                            7
  comment on Postscript fonts [RE: shrink wrap...still safe?]         11

Viruses Rhyme and Reason Discussion
  Viruses Rhyme and Reason - discussion of mindset of writers          2
  Comment on how the author of the "Stoned" virus created it           6

Theoretical Virus Scanning
       (incl: Comments on article in "American Mathematical Monthly")
  Descr. of article in a periodical: "no completely safe computer
     virus test is possible"  [An interesting article]                 9
  Comment on article  [re: virus scanning]                            11
  A proof a la Cohen if a program P1 is a virus....                   13
  Dispute of the proof (or extension of the proof?)                   15
  Dispute of the dispute  [Universal virus scan]                      17
  Theory and real-life don't match                                    17
  Nothing is 100% accurate/also memory protection architechtures      19
  Additional info on proof                                            19
  the halting problem proves that proofs don't work                   20
  In defense of proofs                                                20
  Antithesis of proofs and halting problem                            20
  Either its a virus or it may be a virus                             21
  Proof is: if it's suspecious, don't load it.                        21
  Can't detect viruses that haven't emerged / indecidable if a virus
                      can determine if a prog is a checker program    22
  Dispute / comments                                                  22
  Halting problem comments                                            23
  Is it possible to come up with a universal virus detector?
                                        [virus modeling]              23
  simply check all executibles sizes / Has a copy of program that
               does this.    [W13 Polish text]                        23
  3-page definition of the term "virus"                               24
  Those proofs are irrelevant-can trivally detect viruses thru H/W    25
  Don't understand Leichter-propose "last changed" stamp              27
  can't simply check exec's-WDEF is an ex. of data files propogating
                 viruses [virus propogation in non-executable files]  27

General Topics
  Tracking infections - presentation of possible discussion base       1
  Questions about Virus-L from a new reader                            1
  Don't use progs you can't trust [Do not use this diskette]           1
  Using ASCII 255 to conceal presence of a directory                   1
  Virus researcher's copy of virus shows up in a variant of the
     Icelandic and Dbase virus   [Two Serious Cases]                   3
  Viruses in Bulgaria - he can supply info on some listed viruses     13
  2 new topics - vaccine for errors?; can failed LISTSERVERS make
        networks collapse?  [re: spool..bug or virus,...]             15
  McAfee included top 100 influential leaders in computer industry    15
  Thank-you Usenet folks!                                             20
  Whats the difference between virus and worm?                        21
  Need help in preparing doc on viruses / How to protect public
              access cluster?   [virus info request]                  23
  Answer difference between virus and worm                            24
  Why doesn't someone run an MSDOS emulator in a MSDOS machine?
                [Prophylactic anti-viral suggestion]                  25

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Wednesday, 14 Feb 1990    Volume 3 : Issue 42

Today's Topics:

WDEF at Naval PG School (Mac)
"Expert System" virus scanner
Forwarded: Re: *UNCONFIRMED* PC virus
Re: The AIDS "Trojan" is a Copy Protection System
Retraction of previous statement (Mac)
Strange Beep... (Mac)
AIDS -program? AND Class Action Suit
Can DOS Extensions (indirectly) help fight viruses? (PC)
Re: Jerusalem-B (PC)
Re: Checksums
Re: Identification strings
How to notify campus community members about viruses
The AIDS Trojan as Copy Protection Scheme
The ethics of virus eradication

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

---------------------------------------------------------------------------

Date:    13 Feb 90 20:27:20 +0000
From:    [e-mail] (Jeff Kulp x2174)
Subject: WDEF at Naval PG School (Mac)

        WDEF A was found on one Mac in a restricted use Mac Lab.  The
virus was removed using Disinfectant 1.5.

Jeff Kulp
[e-mail]

[Ed. Due to the sheer volume of WDEF infection reports...  Someone
recently asked for all WDEF infection reports to be sent to the list;
could that person please identify him/herself to me, and I'll start
forwarding these reports directly to him/her?  Thanks.]

------------------------------

Date:    13 Feb 90 22:26:20 +0000
From:    [e-mail] (Russell McFatter)
Subject: "Expert System" virus scanner

[e-mail] (GEORGE SVETLICHNY) writes:
>Now there just _*MAY*_ (note the triple enphasis) be a theorem of the
>following type:
>
>        I. Given such-and-such memory and microprocessor architecture,
>        then any program containing a virus (however that is defined)
>        will necessarily have a certain patern P in the object code.
>        II. Any program that does not contain a virus can be written in
>        a way that does not lead to pattern P in the object code.

I was going to suggest this type of approach myself; if "pattern" is very
loosely defined, as is "virus".  I put forward this simple hypothesis:

        An algorithm (A) exists which can positively determine that a
        given set of programs (Pg) do NOT exhibit harmful behavior.

"harmful behavior" can be defined however we want; self-reproduction,
direct access to hardware, modification of other executables, and so on.

Trivial proof: We can enumerate the set Pg and write an algorithm to
identify a program as "good" if it is included in the set.

This is not ENTIRELY impractical (a program which compares the
executables on a disk to the "original" would fall in this class).
This isn't very useful for most situations.  We need to be able to add
a statement like part II of George's theorem.

        Any program which is NOT harmful can be written in such a way as
        to satisfy algorithm A.

This would be very difficult to prove.  In reality, though:

1:  We are not restricted to a single virus-checking algorithm; we can use a
    number of them (A1 ... An), each of which can "clear" a subset of the
    programs we wish to test.  We may need to know which virus "disprover"
    algorithm applies to each given test subject  ("You can check UltraGame
    PD 1.4 for virus-safety using 'class 5' checking methods").

2:  The set of "harmless" programs is not as clearly defined as we'd like;
    some programs that we'd ordinarily call "harmful" will be, in fact,
    exceptions to the rules.

3:  We'd settle for a set of virus-disproving algorithms that works on MOST
    software, if we have other means to insure the integrity of the
    "exceptions" we need to install.

4:  The usefulness of the virus-disprover varies with the percentage of
    real-world programs that it can successfully clear.

5:  Measures have to be taken to make sure that the virus-disprover's
    environment is "clean".

6:  A set of "safe" system calls could be used to decrease the number of
    "exception" programs. A pair of calls that create/delete temporary
    files, for example, could be considered "safe" by a virus scanner, as could
    most routines which perform "dangerous" acts after prompting the user.
    (PromptDelete, for example, might pop up a dialog box with a message such
    as:  "Ok to delete <filename>?" before deleting the file.  This would be
    considered "safe" by the virus-disprover, unlike the call that deletes
    without prompting.)

We can submit, to the software authors of the world, a set of rules that
they must follow if we are to accept their products (hey, if the world
can stem the copy-protection wars simply by refusing to purchase
any software with copy protection, we can do the same for virus-testability).
These can include all the difficult-to-test issues that have been
mentioned here so far, such as:

        1:  No self-modifying code or execution of data.
        2:  No direct access to hardware-- use approved system calls only.
        3:  No modification of executable files.
        4:  No transformations of "data" files into executables or writing
            executable files (loaders/compilers would fail here).
        5:  Substantial restrictions on calculated (register) jumps
            (designed to accommodate most high-level constructs, but not
            much else).

To some extent, these rules overlap simple good programming practice.
Self- modifying code is hard to debug, direct hardware access is
nonportable, computed jumps are "risky"; the others are generally
"antisocial".

When you think about it, you'll realize that we sometimes DO go this
far to protect ourselves against viruses-- this is exactly what
happens when you review source code before compiling and executing it.
The fact that you're getting (high-level) source code means that the
author has obeyed some rules, making the program easy to understand
(so that you'll trust it), and not writing any "suspicious" or
"dangerous" code. If YOU can "virus-check" a program, it seems
reasonable that a computer could do some of the same, not only faster,
but more reliably.

- --- Russell McFatter  [[e-mail]]
std. disclaimer applies.

------------------------------

Date:    Tue, 13 Feb 90 15:18:34 -0800
From:    [e-mail] (Rollo D. Rogers)
Subject: Forwarded: Re: *UNCONFIRMED* PC virus

hi, does anyone else have knowledge/experience with this alleged PC
virus?

[Ed. As with all such reports, I urge people to NOT BELIEVE this
without some reliable third party confirmation.  We've all seen that
rumors can be just as time consuming as The Real Thing...]

Forwarded mail follows:
Date: Tue, 13 Feb 90 14:52:02 -0800
From: Yong Kim <[e-mail]>
Subject: Re: virus

I went to a local computer store and one of the salesmen complained
about the new kind of virus.  He said that unlike the conventional
ones (residing in the first track or other part of command.com, etc)
this one lives in the setup-memory (CMOS) that was backed up by the
computer battery.  All the infected disketts can be reformated and can
be purified, but this one lives there until human disconnects the
battery from the unit and restart the machine.  The story seems quite
plausible and that's why I decided to hear from experts' opinion on
the net.  Since today's AT usually uses CMOS memory, this looks a
serious problem.  The story went further: once the scan program is
loaded, the virus in there can recognize his eternal enemy (wel I
might be exaggerating, or making a fairly tale..) and destroy it.
Sounds like a SIFI fiction, but it looks like possible.  I wish we had
some kind of ANSI anti-virus detection scheme:-)

------------------------------

Date:    Tue, 13 Feb 90 18:35:00 -0500
From:    [e-mail]
Subject: Re: The AIDS "Trojan" is a Copy Protection System

munnari!mqccsunc.mqcc.mq.oz.au![e-mail] (Ian Farquhar) writes:

>This is not a trojan: it is a COPY PROTECTION SYSTEM.  The
>consequences of using the program without paying are quite adequately
>laid out in the license, which apparently has not been read.

>If the author of this program is convicted, it will be the first
>conviction ever for the hidious crime of writing a copy protection
>system, and will be one of the biggest farces of justice ever
>witnessed.

Well, no.

1. It is unacceptable and actionable that a copy protection system
   delete unrelated material.

2. Why did the "copy protection system" count down from a random
   number before "protecting" things?

3. Unsolicited material received in the mail is the property of the
   recipient, the presence or absence of a licence being immaterial.
   (Or, to be more precise, that is law in this country.)

4. Why did the perpetrators attempt, beforehand, to hide their
   tracks? And why didn't they come forward immediately? A judge
   will interpret this as a clear demonstration of intent.

Don             D.C.Lindsay     Carnegie Mellon Computer Science

------------------------------

Date:    Tue, 13 Feb 90 18:18:00 -0500
From:    Peter W. Day <[e-mail]>
Subject: Retraction of previous statement (Mac)

Dave Platt is correct and I am wrong about the accessibility of the
desktop file on an AppleShare server, and I appreciate his clarifying
the situation.  When I tried it previously, I had neglected to login
to my server with adequate privileges.

------------------------------

Date:    Tue, 13 Feb 90 18:12:08 +1100
From:    "Alejandro Kurczyn S." <[e-mail]>
Subject: Strange Beep... (Mac)

  We have a strange problem here, working on a Macintosh II, sometimes
it beeps when a file is open or closed and sometimes during starup. I
read some time ago that a WDEF (or nVir) sounds the bell when present.
So, I tested the hard disk (20 M) with disinfectant 1.6 and it didn't
show anything. I also re-created the DeskTop file, but the same
problem persist. My questions are:

  Is this a virus?   how can I get rid of it?
  Is a know virus?

Please mail me directly, Thanks in advance.

- -Alejandro J. Kurczyn S.
ITESM CEM
Mexico

------------------------------

Date:    Tue, 13 Feb 90 20:09:06 -0500
From:    woodb!scsmo1![e-mail]
Subject: AIDS -program? AND Class Action Suit

First of all can someone answer this question with a yes or no for
me...  Did the AIDS disk come with an AIDS program??

AND

Is there anyway that a class action suit could be made for those who
suffered damages against a convicted virus writer.  Ie, could those
hit by the famous WORM now sue for damages??

- --
 DON INGLI-United States Department of Agriculture - Soil Conservation Service
 INTERNET: scsmo1![e-mail]    PHONEnet: 314!875!5344
 UUCP(short): uunet!scsmo1!don        UUCP(long): uunet!mimsy!woodb!scsmo1!don
              These are my opinions. I represent myself.
   Who do you think you are, Bjorn Nitmo?  David Letterman '90 Catch Phrase

------------------------------

Date:    Tue, 13 Feb 90 23:10:52 -0600
From:    [e-mail] (Tim Williams)
Subject: Can DOS Extensions (indirectly) help fight viruses? (PC)

I was wondering if running a DOS extension, like 4DOS, which totally
replaces COMMAND.COM, would provide any measure of protection against
a virus attack.  I know that it would not provide any help directly
(as a feature, I mean), but might subtle changes in the OS throw off
some viruses?

------------------------------

Date:    Wed, 14 Feb 90 14:05:07 +0200
From:    Y. Radai <[e-mail]>
Subject: Re: Jerusalem-B (PC)

  Michael Greve writes:
>  I want to thank all the people who sent me messages on using the
>CLEAN program.  Unfortunately the program did not work.  It removed
>the virus and shrank the .exe file from 260,000+ bytes to 84,000.
>Needless to say this file didn't run.  Does anybody have any other
>ways of getting rid of this virus.  Is the Jerusalem virus a
>particularly difficult virus to get rid of???

  Ordinarily, the Jerusalem virus is easy to get rid of using any of
the common anti-virus programs (CLEANUP, UNVIRUS, F-FCHK, VB, etc.).
  However, a few EXE files contain a file-length in their header which
is less than their actual length.  If such a file is infected by the
Jerusalem virus, it overwrites part of the file instead of extending
it.  In that case, it's obvious that no program can restore the file.

  There's seems to be some misunderstanding on this subject.  For
example, Brad Fisher writes:
>                                              The only problem is that
>this paticular flavor of virus can not always be removed without some
>damage to the original file ... but a least it can be removed!

This is misleading; it sounds as if the disinfecting program does the
damage.  If the virus hasn't overwritten the file, I don't think any
of the above programs ever damage the file.  And if it has overwritten
it, then the truncation performed by the program doesn't matter.

                                     Y. Radai
                                     Hebrew Univ. of Jerusalem, Israel
                                     [e-mail]

------------------------------

Date:    Wed, 14 Feb 90 13:51:12 +0200
From:    Y. Radai <[e-mail]>
Subject: Re: Checksums

  IA88000 asks:
>If you had your choice, which checksum routine would you consider most
>secure, and why. ....
>To make the question a little more specific, of the checksum routines
>available today, which would you select.

  It's strange that Mr. IA88000 makes no reference to the discussion
which has been taking place so far on this forum.  We've been talking
of checksum *algorithms* and checksum *programs*, and I'm not sure
which he's referring to when he writes "routine".  And if he means a
*program*, then for what computer.  Since I have already answered the
question in the case of algorithms, I'm going to assume here that he's
asking which *PC* checksum *program* available today do we consider
best or most secure.

  Among those that I've seen, the one which is certainly the most se-
cure, and probably best all around, is V-Analyst (name changed from
VirAlarm to avoid conflict with another product of the same name).  I
know the authors, Omri Mann and Yuval Rakavy, but that in no way in-
fluences my evaluation.
  It's a commercial product, costing $79.  It implements Prof. Rabin's
CRC algorithm in which the generator is chosen at random from among
all 31st-degree irreducible polynomials when each user initially sets
up his checksum base.  It is activated either on demand or by virtue
of the command being placed in AUTOEXEC.BAT (which does not necessari-
ly mean that it must be activated on *every* boot), and does not re-
main resident.  The user is given complete control over selection of
the files which are to be checksummed (e.g. one can choose to checksum
a small set of files on every boot and all files on the disk every two
weeks) and both the initial selection and subsequent updating can be
performed very conveniently, by wildcard notation and/or by "pointing-
and-shooting".

  Most important, great care has been taken to prevent virus writers
from circumventing the checksumming.  This is the only program I've
seen which blocks every loophole in DOS that I know of, provided check-
summing is performed only when memory is uninfected (i.e. immediately
after booting from a clean diskette).
  In May 88 this program was the subject of a $6000 bet on Israeli
television.  A software house threw 10 specially-written test viruses
at it, and none succeeded in going undetected.  (Although the attack-
ers lost the bet, so did the defenders.  Apparently, the judges deci-
ded that in order to win, the latter would have to prove that their
program could detect *all possible* viruses!)

  Checksumming a given file takes about 3 times as long as performing
a COPY of that file to NUL.  (This is on an XT; the factor is probably
smaller than 3 on a faster machine.)  The checksum feature of FSP is
somewhat faster than this (it uses a simpler algorithm than CRC), and
Sentry is much faster (since it checksums only the beginnings of
files) and therefore will be preferred by some users.  But both Sentry
and FSP are potentially insecure.  Also (as I mentioned previously),
checksumming in FSP is extremely tedious (apparently the commercial
version FSPP is less so), and Sentry suffers from a lack of flexibi-
lity, particularly when it becomes necessary to update the checksum
base.

                                     Y. Radai
                                     Hebrew Univ. of Jerusalem, Israel
                                     [e-mail]

------------------------------

Date:    Wed, 14 Feb 90 14:18:37 +0200
From:    Y. Radai <[e-mail]>
Subject: Re: Identification strings

Fridrik Skulason:
>         Identification string: A sequence of bytes, used by anti-virus
>         programs to check if a program is infected.
>         Signature string: A sequence of bytes, used by the virus to check
>         if a program is infected.

David Chess:
>Well, by an unhappy coincidence, we tend to use the terms more or less
>the other way around, around here.  We call the thing that a virus
>checks for the "self-identification", and we call the things that our
>scanner scans for "signatures".

  Since the term "signature" already has too many meanings (checksum,
for example), I suggest as a compromise that we drop it entirely and
use the terms "scan-id" and "self-id" instead, i.e.:

Scan-id = a string (or set of strings) used by an anti-virus identifi-
          cation program to check if a program is infected by a known
          virus;
Self-id = a string or pattern used by a virus to detect if a program
          is already infected by it (or perhaps by some related virus).

                                     Y. Radai
                                     Hebrew Univ. of Jerusalem, Israel
                                     [e-mail]

------------------------------

Date:    Wed, 14 Feb 90 08:43:45 -0500
From:    [e-mail] (Eloise Kleban)
Subject: How to notify campus community members about viruses

Getting the word out to faculty, students and staff is a major problem
that computer center consultants face.  If you don't publicize the
problem, you may be liable in some sense for damage that occurs.  On
the other hand, you must avoid accusing individuals or groups.  For
example, most of the virus infections I see are on faculty machines,
and one major reason is the sharing of computer software that goes on
among them.  (There are other people on campus who deal more with
students - I'm not implying that the students don't spread viruses
also!)  This is an issue that must be handled diplomatically.

I publish articles in our newsletter, I make sure that the other
consultants in the University system have the same info I have and the
software tools, and every time I talk to a user about micro software,
I mention the problem of viruses.  However, we are very careful not to
point any fingers.

Eloise Kleban                     BITNET:   ELOISE@MAINE
Computing Center                  INTERNET: [e-mail]
University of Maine

------------------------------

Date:    Wed, 14 Feb 90 09:28:00 -0500
From:    Jim Shanesy <[e-mail]>
Subject: The AIDS Trojan as Copy Protection Scheme

When the AIDS trojan alerts first appeared I faxed them to a dear
friend of mine, Mr. Paul R. Paletti, Jr., Esq. of Siler and Handmaker
in Louisville, Ky.  Paul is a licensed, practicing attorney at law.
He gave me his informal opinion over the phone as to the significant
facts in the case, to wit:

1) The disk was unsolicited and was sent through the mail.  The
recipient therefore owns the disk outright and the sender is
automatically waiving any rights to ownership.  The whole concept of
"copy protection" goes right into the dumpster at this point.  Paul
was very emphatic in pointing out that there is no defense on this
point. He said this is the most significant legal fact in the case.

2) The software on the disk sabotages another's personal property,
with an accompanying demand for money.  This is blatant extortion.  No
matter how profuse and explanatory any printed disclaimers may be, the
intent is clear.  The author is attempting to profit by placing
another individual under duress.

That boy's in a heap o' trouble.

Jim Shanesy <[e-mail]>
Office of Computer and Information Technology
National Research Council
2101 Constitution Ave., NW
Washington, DC  20418

[Ed. Is this the case under British law as well as U.S. law?  If he
did this in Britain, did he break any U.S. laws?  Will Dr.  Popp be
tried here or in Britain?  Just a few thoughts...]

------------------------------

Date:    Wed, 14 Feb 90 10:22:39 -0500
From:    Kevin_Haney@NIHDCRT
Subject: The ethics of virus eradication

With regard to Alan Federman's questions concerning the ethics of
virus eradication, it has unfortunately become the prevailing tendency
in many quarters, especially the business world, to deny and try to
cover up incidences of viral infection.  However, the situation boils
down to this: A computer professional does not (usually) take any sort
of oath of confidentiality.  His primary responsibility is to the user
community as a whole, not to any single individual.  That does not
mean, however, that reports of viral attacks should be distributed
indiscriminately.  As a professional, you have a responsibility to
balance the feelings of the 'infectee' and the dangers of unnecessary
hype against the danger of the possible spread of the virus and the
potential damage it may cause to other people in the community.

I don't know the particular circumstances of Federman's situation, but
it sounds like he did exactly what should have been done.  If there is
a good probability that telling people about a particular virus might
prevent them from getting it, then that should outweigh the potential
embarrassment that a single person might suffer (especially since
Federman did not reveal the particular name of the person involved).
If someone were to contract the virus later and learned that you had
known about it but did not warn anyone, the professional and political
repercussions would most likely be greater than the scoldings of one
irate faculty member (many of whom have a tendency to become irate
with little provocation).

To again revert to the medical analogy (which is admittedly
imperfect), what if a physician who treats a very contagious disease
refused to report it to the National Center for Disease Control and,
as a result, the disease spread further.  That would amount to an
abdication of responsibility on the part of the physician tantamount
to malpractice.  The only situation where withholding the information
would be permissible would be when, for some reason or other, there
was little chance that the disease (or virus) would spread any
further.  Since there were a number of people on Federnam's campus
studying fractals, there was a good possibility that someone else
might have purchased or come across the infected program and thereby
spread the virus further.  So, while we all have to deal with
unreasonable people occasionally, I do not think Federman's actions
lacked any professional or ethical justification.

    _______________________________________________________
   |                                                       |
   |   Kevin Haney, Computer Specialist                    |
   |   Division of Computer Research and Technology        |
   |   National Institutes of Health                       |
   |   BITNET - Kevin Haney:dcrt:nih                       |
   |_______________________________________________________|

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Thursday, 15 Feb 1990    Volume 3 : Issue 43

Today's Topics:

Re: The ethics of virus eradication
Re: Many WDEF reports (Mac)
Strange Macintosh Beeps (Mac)
Algorithms
WDef hits Carleton
Undetectable Virus (Mac)
Re: The AIDS "Trojan" is a Copy Protection System
Re: Forwarded: Re: *UNCONFIRMED* PC virus
Dr. Popp
Universal Virus Detector
New virus in Canada??? (Mac)
UNIX discussions?
Re: Many WDEF reports (Mac)
Virus Buster (PC)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

---------------------------------------------------------------------------

Date:    14 Feb 90 20:06:52 +0000
From:    [e-mail] (Joshua M. Alden)
Subject: Re: The ethics of virus eradication

[e-mail] writes:
>This week (Feb 5th-9th, 1990) marked the first occurrence of PC
>computer viruses on our campus. First our Library received the census
>disk, which we were warned of, and secondly a faculty member was
>infected by Jerusalem B. I was able to clean-up this system with some
>effort in about an hour. This was the last thing I did on Thursday
>afternoon. On Friday, I posted mail to all campus mainframe account
>holders (most of our campus users since our PC network is just in the
>beginning phase) about the two incidents, and how to avoid virus
>infections. In this E-mail message, I was particularly careful not to
>mention the name or department of the faculty member involved.
>
>Well, that didn't work. The faculty member was extremely angry about
>the E-mail message. I did mention the type of program that was the
>supposed virus vector. He contended that anyone on campus would figure
>out his identity from the type of program (fractals), since he was
>teaching a continuing course on the subject. I won't go into the
>details of the venom that was directed my way.
>
>My questions are these - what should I have done? Kept the infection
>secret? Are computer viruses a Social Disease? Are we physicians who
>are supposed to swear some form of Computerized Hippocratic Oath of
>confidentiality? Or, do we paint a Scarlet-V on the heads(or
>terminals) of those unfortunate ( careless enough) to become infected?
>I would like to hear of similar experiences and policies enacted to
>deal with virus infections.

Alan -

    It sounds to me as though you did exactly the right thing.  Taking
reasonable care not to reveal who was affected by the virus was a
responsible action.  So was informing as many people as possible of the
incident in order to prevent any more damage.

    I don't know how you phrased the e-mail message, but my guess is
that you did not insult the faculty member, nor imply awful things about
his character.  Why he was upset I really can't imagine; most of us have
been infected at one point or another, whether through carelessness,
lack of knowledge, or whatever.  Having been hit with a computer virus
certainly shouldn't be cause for ostracism or any other sort of punitive
behavior.

    Furthermore, unless that fractals program was a very specific one, I
doubt that it pointed to him any more specifically than any other
program that generates wierd graphic output.  In high school, a friend
of mine and I used to generate pretty color designs on his PC using a
Mandelbrot program.

    I wouldn't worry about it too much, unless the professor continues
to give you trouble about it.  Education is the key in the anti-viral
world, as it is in any situation involving an epidemic.  Trying to
conceal outbreaks, especially when the worst result is embarrassment, is
foolish.

- -Josh.

 /--------------------------------------------------+-------------------------\
 |Josh Alden, Consultant, Kiewit Computation Center | HB 48, Dartmouth College|
 |   Private mail: [e-mail]       | Hanover, NH     03755   |
 |    Virus mail:   [e-mail]        |      [phone]     |

------------------------------

Date:    Wed, 14 Feb 90 12:16:31 -0600
From:    John Norstad <[e-mail]>
Subject: Re: Many WDEF reports (Mac)

[e-mail] (David.M..Chess) writes:
> Curious as to why we're seeing all these WDEF reports, and not similar
> numbers of reports of other widespread viruses.  Has it just become a
> tradition to report WDEF on VIRUS-L, or is WDEF better at spreading?
> If the latter, does anyone have a good feeling for what about WDEF
> makes it so (um) virulent?  DC

WDEF now appears to be the most widespread of all the Mac viruses - more
widespread than even nVIR A and B.  I don't know why.  I do know that by
the time it was discovered in early December of 1989, it had already
spread very widely.  We clearly didn't catch it until it had been around
for quite some time.

One reason for not being detected earlier is almost certainly that WDEF
contained special code to get past all but one of the popular virus
protection INITs.  All of these INITs have since been improved to catch
WDEF, but when it first began to spread only AntiToxin would catch it - it
got past Vaccine, GateKeeper, SAM Intercept, and the Virex INIT.  This is
a problem with the general-purpose suspicious activity monitor virus
protection INITs on the Mac - with enough effort a new virus can evade
their protection measures.

A properly used checksumming system is clearly the most reliable way to
catch new viruses.  This topic has been beaten to death on virus-l.  The
problem with such systems is convincing users to make use of them.

WDEF is also clearly one of the most buggy Mac viruses.  It doesn't
attempt to do any damage on purpose, but it does contain bugs which can
and do cause almost anything to go wrong with the proper functioning of
Macintoshes.  We've seen everything from problems with the proper display
of font styles to trashed disks.

I don't think it's necessary for everybody to report every sighting of
WDEF here on VIRUS-L.  I gave up trying to keep track of all the sightings
a long time ago - it's everywhere.

It's also interesting that WDEF appears to be much more widespread outside
the university environment than any of the previous Mac viruses.  The
so-called "serious business community" (as if universities somehow don't
count in capitalist America) is getting hit hard.  Perhaps the silver
lining in this very dark cloud will be an increased awareness of the
problem among the public, and perhaps people will even finally start to
take measures to protect their machines.

The Mac anti-viral community did an excellent job of combatting WDEF.
Within two days of the discovery of the virus we had disassembled and
analyzed the virus and informed the public with accurate, complete
information.  Within a week there were tools available for detecting and
eliminating the virus.  Within two weeks there were tools available that
actually worked properly :-).  We have established a very effective group
on the Internet of anti-viral tool authors (commericial, shareware, and
freeware) and other experts which goes into high gear whenever a new
virus, Trojan, or other kind of destructive Mac software appears.

John Norstad (author of Disinfectant)
Northwestern University
[e-mail]

------------------------------

Date:    Wed, 14 Feb 90 16:07:15 -0500
From:    [e-mail] (David Gursky)
Subject: Strange Macintosh Beeps (Mac)

If you do not have Macintalk in your System Folder, the nVIR virus
will cause the Mac to beep (or make whatever sound is selected as the
System Beep) on a periodic basis.  The period is well defined, but I
do not know it.  If Macintalk is installed, the Mac will speak "Don't
worry".

WDEF does not make any noises.

------------------------------

Date:    Wed, 14 Feb 90 14:25:36 -0500
From:    [e-mail]
Subject: Algorithms

   Could someone provide a bibliography on the subject of data
verification algorithms (CRC, MD4, ...)?  Reply to me or the list.
Assume access to good public and university libraries.
                             Thank you,
                             David R. Conrad

BITNET: [e-mail]
"You cannot propel yourself forward by patting yourself on the back."

------------------------------

Date:    Wed, 14 Feb 90 15:37:00 -0600
From:    "Paul Duckenfield (Consultant, User Services)" <[e-mail]>
Subject: WDef hits Carleton

        For the past four or five months, the Carleton College Micro Lab
has been plagued by inexplicable crashes. In the past month, the crashes
have escalated in volume to as many four or five a day. Here is our
configuration-

        Macintosh IIcx file server
                o 2 MB RAM
                o twin 40MB HD's (one internal, one external, both Apple)
                o AppleShare v2.0.1
        22 Macintosh Pluses in a Lab (LocalTalk)
                o 2.5MB RAM
                o Running RAM disks
         8 Macintosh Pluses in a remote lab (served by TOPS Repeater)
                o same as above
        10 Staff Macs scattered throughout offices
                o various types (CX, Plus, SEHD)
        All running System 6.0.3 (except CX's which run 6.0.4)

        sometimes we run the Apple Print Spooler, but sometimes we have
trouble with that.

        Symptoms:

                o Print Spooler crashes 15 minutes before server (that is
                        why we don't always use it)
                o Internal HD light on server turns on and stays on
                o Everyone gets the "watch" when they attempt to access
                        the server and it never goes away
                o restarting the IIcx and the workstations temporarily
                        solves the problem (until the next crash!)

        What we did:

                Reformatted the HD from scratch and reinstalled software.
The server still crashed. Then we ran Disinfectant v1.6. It told us that
the server was infected with WDef. We removed WDef. Problems began appearing
a few days later, same as before. Again we checked for WDef, but it wasn't
there. A few days later, it reappeared (it is possible that it accidentilly
found its way in through a server administration disk).
                Finally, we killed the DESKTOP file to prevent WDEF from
having a refuge of any sort. This appears to have worked for there haven't
been any crashes in awhile.

        Conclusions-

        o WDef is never "really" eradicated, even when Disinfectant kills
it. Like pnuemonia, it goes away, but lasting damage remains.
        o WDef infections to file servers can be prevented by canning the
                DeskTop file which is unused.
        o WDef is extremely virulent and elusive.

                        Paul Duckenfield
                        Micro Consultant
                        Carleton College
                        User Services
                        [e-mail]

------------------------------

Date:    14 Feb 90 21:58:28 +0000
From:    [e-mail] (Betty Harvey)
Subject: Undetectable Virus (Mac)

        I have seen two Macintoshes that have a virus that I can't seem
to recognize.  I have run Disinfectant 1.6 because I thought it was the
WDEF virus that I have been reading about but disinfectant didn't find
anything abnormal.  I have also ran several other virus eradicaters and
they didn't recognize anything out of the ordinary.

                        Symptoms:

        The system file increases in size and the date changes
        each time the system is rebooted.  One system file was
        2 meg long before all application program ceased to work.

        Applications unexpectedly stop.

        The system hoses up occasionally when going to the printer.

Is anyone aware of any new viruses or what I might be dealing with.
We had a massive outbreak of Scores and nVir about 1 year ago, but
have had fairly healthy machines since then.
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Betty Harvey  <[e-mail]>              |
David Taylor Research Center                        |
Office Automation/Microcomputer Support Branch      |
Bethesda, Md.  20084-5000                           |
                                                    |
[phone]                                       |
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\\/\/

------------------------------

Date:    14 Feb 90 16:49:40 +0000
From:    attcan![e-mail] (Richard Meesters)
Subject: Re: The AIDS "Trojan" is a Copy Protection System

Interesingly enough, much of the previous discussions that I read on
this topic (and posted on, as well) has little to do with the fact
that a demo version of the software can have a self-destruct mechanism
(a time bomb).

However, what we are dealing with here is the fact that this program
does not destroy itself, but rather renders all your programs and data
un-usable.  In fact, you have no evidence to back up the fact that
even if I did send in the money for the purchase of the program, that
I would get the fix back.  The fact that the address was an unknown
post-office box in Panama seems to indicate that the whole thing was a
scam.

I agree that if the persons receiving this program had read the
notice, they probably wouldn't have installed the program, but don't
confuse that with justifying the actions taken by the program after
installation.

The issue here is, in my opinion, twofold.  First, did the auhor of
this trojan commit a fraudulent act.  And can someone who sends you an
un-solicited copy of a program make you pay for the use of the
package.  This was NOT a demo version of the software, from all
indications.

Regards,

- ------------------------------------------------------------------------------
     Richard A Meesters                |
     Technical Support Specialist      |     Insert std.logo here
     AT&T Canada                       |
                                       |     "Waste is a terrible thing
     ATTMAIL: ....attmail!rmeesters    |      to mind...clean up your act"
     UUCP:  ...att!attcan!ram          |
- ------------------------------------------------------------------------------

------------------------------

Date:    15 Feb 90 00:31:53 +0000
From:    [e-mail] (Kelly Goen)
Subject: Re: Forwarded: Re: *UNCONFIRMED* PC virus

[e-mail] (Rollo D. Rogers) writes:
>hi, does anyone else have knowledge/experience with this alleged PC
>virus?
>
>[Ed. As with all such reports, I urge people to NOT BELIEVE this
>without some reliable third party confirmation.  We've all seen that
>rumors can be just as time consuming as The Real Thing...]
>
>Forwarded mail follows:
>Date: Tue, 13 Feb 90 14:52:02 -0800
>From: Yong Kim <[e-mail]>
>Subject: Re: virus
>
>...
>this one lives in the setup-memory (CMOS) that was backed up by the
>computer battery.
>...

Well sorry this one isnt plausible... infectious code will not be
using CMOS to spread from(standalone...) just isnt enough memory in
there on standard AT architectures...on Micro-channel there is enough
space...  however the data is simply read or written not executed...
(n.b. I have run into programs which through programming mistakes
rendered CMOS data unusable... but not a virus living in
there...caused by poor coding though not a virus or trojan) this one
kind of reminds me of the hilarious(at least to myself and chuck
forsberg) MODEM virus SCARE of 1988(NO IT wasnt and isnt REAL)...
     cheers
     kelly
p.s. on microchannel architectures there is adequate unused space in
cmos adapter ram... but another cooperating process would be needed
to read the cmos for the code and place it into main memory as
code cannot be executed in CMOS RAM Buffers...

------------------------------

Date:    Wed, 14 Feb 90 19:26:00 -0500
From:    [e-mail]
Subject: Dr. Popp

>Ed: ... did he break any U.S. laws?  Will Dr.  Popp be
>tried here or in Britain?  Just a few thoughts...]

Dr. Popp was arrested in Willowick, OH on an extradition warrant.  He
is not charged with any crime in the US.  His defense against
extradition is technical, i.e., being treated for mental problem, not
substantive.  [It is a mere coincidence that Dr. Popp and RTM hold
degrees from the same elite institution.  Few inferences would be
justified.]

William Hugh Murray, Fellow, Information System Security, Ernst & Young
2000 National City Center Cleveland, Ohio 44114
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840

------------------------------

Date:    Wed, 14 Feb 90 18:49:00 -0500
From:    "Science:Controlled Paranoia" <[e-mail]>
Subject: Universal Virus Detector

I agree with Russell McFatter's [[e-mail]] rules in that
they would work.  However, I don't believe it would be successful with
some shareware products, or quick-fixes/patches.  Not that any of us
INTENTIONALY program that way, but at 3 in the morning when a quick
long jump will solve the problem over rewriting an entire 5000 line
module...  And as (it would seem) more people contract viruses through
shareware than anything else, the problem is compounded.
     I am curious as to why everyone seems to stick to a Universal
Virus Detector that 'detects on the fly.'  Wouldn't it be more feasible
for a Universal Virus Detector to act as more of a high-security Operating
System, than a program?
Let me elaborate...

Boot up a PC from a clean DOS, then implement this Virus Detection
Operating System (VDOS).  VDOS now clamps down on every interrupt, AND
watches for every redirect interrupt command.  Then you give it a
program to check.  VDOS pseudo-executes the program, checking for
every possible outcome and attempts to write to disk.  Any attempt to
write to an area locked out by you constitutes a virus.  (Or at least
something not kosher...)  Theoreticallly, so long as the VDOS isn't
contaminated, and so long as you don't add a program that hasn't been
checked, you're clean.  The positives for this are 1.  Unhampered
program execution.

2.  More control over Virus checking then 'check on the fly' detection.
  (algorithms can be more complex...)

The negatives are
1.  Time to detect.  I'm figuring this may take awhile for long programs.
It may not even be feasible with large menu driven programs...
(DBase IV, and Lotus 1-2-3, for example) to check every possible outcome
or result...(But if you're willing to wait an hour to backup your
hard drive, maybe its worth it?)

2.  Wouldn't defend against viruses that just replicate themselves, unless
you looked for it specifically.

3.  Of course it's not 100% fool-proof.

Overall though, you could have more complex algorithms than a virus-scanner,
plus more control than a memory resident detector (flu-shot).
But then this was all just a thought, anyway.

(Oh, once you've finished with the program, you then reboot to Normal DOS,
with the knowledge of whether or not you have an infected disk...)

Charles Cafrelli   Bitnet:  IAQR100@INDYVAX
Computer Constultant for the IUPUI English Department
Disclaimer:
"I don't know what they're saying, and they don't know what I'm saying."

------------------------------

Date:    Wed, 14 Feb 90 21:37:07 -0700
From:    Ben Goren <[e-mail]>
Subject: New virus in Canada??? (Mac)

I have heard rumors from people here at Arizona State University that
there is a new Macintosh virus on the loose.  I am currently trying to
trace these rumors, and will let the list know when I hear anything.

It is supposed to be intentionally and maliciously destructive, has not
yet made it out of Canada, and "Disinfectant probably won't catch it."
(the person who said that was not an overly experienced Mac user).

Let's keep our fingers crossed that this is just a rumor.

........................................................................
 Ben Goren                                               T T T        /
     Trumpet Performance Major                    )------+-+-+--====*0
     Arizona State University                        ( --|-| |---)
     Internet: [e-mail]        --+-+-+--
........................................................................

------------------------------

Date:    Thu, 15 Feb 90 04:24:18 +0000
From:    SMSgt Michael L. Shamel <email!lgdelta![e-mail]>
Subject: UNIX discussions?

I have just started monitoring this group and am new to the unix
environment.  Has there been any discussion on viruses trojans or
other nasty things that unix systems are vulnerable to?  I am
particularly interested in how one guards against things sent through
the internet either by regular mail, or some of the UUCP processes.
uux seems like a particularly good candidate for mischief.  If this
subject has come up before, please point me in the direction of the
proper archive.

                Thanks
                Mike Shamel....

------------------------------

Date:    15 Feb 90 01:48:18 +0000
From:    MINICH ROBERT JOHN <[e-mail]>
Subject: Re: Many WDEF reports (Mac)

[e-mail] (David.M..Chess) writes:
> Curious as to why we're seeing all these WDEF reports, and not similar
> numbers of reports of other widespread viruses.  Has it just become a
> tradition to report WDEF on VIRUS-L, or is WDEF better at spreading?
> If the latter, does anyone have a good feeling for what about WDEF
> makes it so (um) virulent?  DC

  I don't know about the "tradition" part, but WDEF is easily the most
virulent entity on the Mac, and probably any computer. The only way to
make it spread faster would be to have all the Macs connected together
with zero protection of the desktop files. All it takes is one
insertion of an infected disk, and the unprotected machine gets it.
Kind of like what some weird people used to (still do, perhaps?) think
about AIDS (the human kind.) "Touch someone and you get it."

Robert Minich
[e-mail]
Oklahoma State University

------------------------------

Date:    Thu, 15 Feb 90 15:36:24 +0200
From:    Yuval Tal <[e-mail]>
Subject: Virus Buster (PC)

About a month or so, I've posted a message about beta testers for the
next version of Virus Buster. Well, a few days after posting this
message, a big software house here, in Israel, have asked Uzi, the
second author, and me about whether we agree to sell Virus Buster to
them. After thinking about it, we've decided to agree and sell Virus
Buster to them.

Here I would like to thank all the beta-testers who accepted to test
Virus Buster. Thank you guys! But now, of course, it would be improper
to ask them to test it.

Another version with bugs correction will probably be released soon,
but I can't promise.

Thank you very much,

               Yuval Tal

+--------------------------------------------------------------------------+
| BitNet:   NYYUVL@WEIZMANN        Domain: [e-mail] |
| InterNet: [e-mail]                        |
+----------------------+---------------------------------------------------+
| Yuval Tal            | Voice:   [phone]  (In Israel: 08-474592)    |
| P.O Box 1462         | BBS:     [phone] * 20:00-7:00 * 2400 * N81  |
| Rehovot, Israel      | FidoNet: 2:403/136                   (CoSysop)    |
+----------------------+---------------------------------------------------+
|  "Always look on the bright side of life" *whistle*  -  Monty Phython    |
+--------------------------------------------------------------------------+

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Friday, 16 Feb 1990    Volume 3 : Issue 44

Today's Topics:

Re: The AIDS "Trojan" is a Copy Protection System
New Virus???? (Mac)
CMOS viruses? Nonsense! (PC)
Virus posted to VALERT-L (PC)
Copyright in viral code
re: Universal Virus Detector
re: AIDS program (PC)
Re: The AIDS "Trojan" is a Copy Protection System
Pakastani Virus (PC)
Re: The ethics of virus eradication
Re: AIDS Trojan - self protection
Re: Undetectable Virus (Mac)
Re: The AIDS "Trojan" is a Copy Protection Systemy
Re: Virus Buster (PC)
Re: The ethics of virus eradication
Ohio Virus: Old Dominion U (PC)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

---------------------------------------------------------------------------

Date:    Wed, 14 Feb 00 19:90:05 +0000
From:    microsoft![e-mail]
Subject: Re: The AIDS "Trojan" is a Copy Protection System

>4.   That the people hurriedly disassembling the program actually
>     committed a breach of the license agreement, and are liable
>     for legal action from PC Cyborg.  Equally, copying of this
>     program is as illegal and is as much piracy as copying any
>     commercial program.

    When a person or company holds property hostage, then lesser laws
can be broken to effect the release of this property.  There
is clear precedent for this.

>I am stunned at the sheer volume of pointless garbage that this
>program has generated, and it makes me seriously doubt any other
>information received from these "experts".  I would also point out
>that self-destructing programs are not new, but one has never caused
>such an outcry before.

   SELF destructing programs are one thing, programs that hold your
computer hostage are another.  It was distributed the way free bars of
soap are distributed.  How would you like to get a bottle of detergent
in the mail that said in fine print "This bottle of soap is not free,
if you use it, send $189.00 to blah blah.  If you don't, you won't
like the consequences.".  Since of course no one reads junk mail, you
use the soap.  It then commences to turn your clothing blue.  THEN you
read the bottle to see what is going on.  If the manufacturer wasn't
arrested, I would sue them for damages.

>If the author of this program is convicted, it will be the first
>conviction ever for the hidious crime of writing a copy protection
>system, and will be one of the biggest farces of justice ever
>witnessed.

    Tell me, what products do you make? I don't EVER want to
use/buy/look at anything from someone that believes he has the right
to cripple my computer if I don't read the fine print.

Brad Thompson                                          [e-mail]
- --------------------   Disclaimer under construction   --------------------

------------------------------

Date:    Thu, 15 Feb 90 13:34:55 -0500
From:    "Chris Khoury (Sari's Son)" <[e-mail]>
Subject: New Virus???? (Mac)

      I was looking thru my Hard Disk today with Disk Tools II (DA)
and noticed a file: _(A2002646)_ on my HD, it's file attributes were
No Copy and Invisibly the File Type is LISA and the Creator is DALE.
It was created on 9/2/02 and it is 2.5K. Anybody know what this is?

------------------------------

Date:    15 Feb 90 19:38:00 +0700
From:    [e-mail]
Subject: CMOS viruses? Nonsense! (PC)

Hi!

Rollo D. Rogers (vol. 3, issue 42) writes:

>this one lives in the setup-memory (CMOS) that was backed up by the
>computer battery.  All the infected diskette can be reformatted and can
>be purified, but this one lives there until human disconnects the
>battery from the unit and restart the machine.  The story seems quite
>plausible and that's why I decided to hear from experts' opinion on
>the net.  Since today's AT usually uses CMOS memory, this looks a
>serious problem.

Nonsense! There are only 64 bytes there and only the half of them are
not used (these at offsets 11h, 13h, 1Bh-2Dh, 34h-3Fh). And even if
someone is smart enough to write such a small virus (which I claim to
be also impossible on 80x86 based computer), these bytes are not
directly addressable. This means that you cannot *execute* the code
which resides in them. You have prior to extract it (using some IN and
OUT instructions). But the code, which will be able to do this *ought*
to reside somewhere else.

Yes, it is possible to design a virus, which will be able to use the
CMOS RAM as a storage for, say, some flags, but not for its entire
code!

>The story went further:  once the scan program is loaded, the virus
>in there can recognize his eternal enemy (well I might be
>exaggerating, or making a fairly tale..) and destroy it.

Nonsense! By the way, which scan program? There are hundreds of them
and they are all different.


  Michael Greve writes:
>  I want to thank all the people who sent me messages on using the
>CLEAN program.  Unfortunately the program did not work.  It removed
>the virus and shrank the .exe file from 260,000+ bytes to 84,000.
>Needless to say this file didn't run.  Does anybody have any other
>ways of getting rid of this virus.  Is the Jerusalem virus a
>particularly difficult virus to get rid of???

and Y. Radai (vol. 3, issue 42) responds:

>  Ordinarily, the Jerusalem virus is easy to get rid of using any of
>the common anti-virus programs (CLEANUP, UNVIRUS, F-FCHK, VB, etc.).

Maybe Michael Greve is trying to disinfect files infected with
Jerusalem B with a program designed for files infected with Jerusalem
A? This is just a suggestion, I do not know neither Jerusalem B, not
the packages, mentioned by Y. Radai.

------------------------------

Date:    15 Feb 90 00:00:00 +0000
From:    "David.M..Chess" <[e-mail]>
Subject: Virus posted to VALERT-L (PC)

Looks like a new one to me!  Very preliminary (possibly wrong)
description:

  - Infects both EXE and COM files.
  - Once the virus is in memory (after the first infected file
    is executed), any vulnerable COM or EXE file that
    is executed via INT 21h function 4Bh will become infected.
    (Vulnerable COM files are uninfected files larger than 999
    bytes and smaller than roughly 62500 bytes; vulnerable
    EXE files are uninfected and larger than about 1500 bytes).
  - If the current month is September, October, November, or
    December, all writes done via INT 21h function 40h will be
    interfered with (the write-buffer register will have 0Ah
    added to it before the write).

This is all from disassembly, not from testing!

The virus is quite unreliable; it loads its resident part into address
9800:0000, without first checking to see if that memory is in use, or
even exists.  The virus will therefore not work on a machine with less
than 640K of memory, and it will cause malfunctions on any 640K
machine that is *using* 9800:0000 for something.  It also does some
rather cutesy things to try to defeat people trying to execute it from
within a debugger, and to take over INT 21 without anyone noticing.
The things add to the unreliability of the virus, but don't make it
significantly harder to detect or analyze.

Here's one possible scan-id (good term!):
22032E8B1E9B00B440CD218B

This may be of use to anyone who "accidentally" downloaded and tried
out the code from VALERT-L!  (Personal opinion: this virus is
incompetent enough that it will always be rare, if it doesn't
immediately go extinct.)

DC

[Ed. Many thanks for the analysis, Dave!  John McAfee has a new SCAN,
version 58 that scans for this virus, dubbed (by John) as the 1559
virus.  I've sent SCAN version 58 to Jim Wright for posting to the
VIRUS-L/comp.virus archive sites.  Thanks to everyone who responded so
quickly to this problem!]

------------------------------

Date:    Thu, 15 Feb 00 14:37:29 +0000
From:    Stuart Milligan <[e-mail]>
Subject: Copyright in viral code

> M.J. Crepin-LeBlond suggests that all you have to do to make having
> virus code once something has been released in some form
> (uncopyrighted) to the general public, it could then never be
> copyrighted.

                     Steven C Woronick

> Well, if it's written in the United States, it's copyrighted automatically as
> soon as it's written to disk.  Anything 'recorded in a fixed medium of ex-
> pression' is automatically copyrighted, with the rights going to the author,
> unless she gives them up voluntarily...At any rate, I'm certain that, if Sam
> Sociopath locks himself up in a Las Vegas hotel room and writes a virus, the
> copyright belongs to him. (Unless he makes it public domain, transfers the
> rights, or is being paid by another to write the virus.)

                     Greg Broiles

Under the United States 1909 revision of the Copyright Act, it was
indeed true that if a copyright owner failed to meet the formal
requirements of a copyright notice cast in the correct format, the
work was automatically forever thrust into the public domain.
However, with the advent of the 1976 revision of the law, notice
standards were somewhat loosened.  If an author failed to publish the
notice as prescribed by sections 401-403, the copyrights would not
always be forever lost or injected into the public domain, provided
that "the notice has been omitted from no more than a relatively small
number of copies...dis- tributed to the public" [the courts will have
a heyday with the term 'relatively small'] or that "registration for
the work has been made before or is made within five years after the
publication without notice, and a reasonable effort is made to add
notice to all copies...that are distributed to the public in the
United States after the omission has been discovered" [the phrase
'reasonable effort' is another one of those rubbery concepts] (see
section 405, subsection (a), clauses (1) and (2)).

It should also be noted that anyone who innocently infringes a
copyright where the copyright notice has been omitted, "incurs no
liability for actual or statutory damages...if such person proves that
he or she was misled by the omission of notice". (see subsection (b)
of section 405)

So, no longer is a copyright truly invalidated forever due to lack of
copyright notice.  This would imply that the author of a viral code
could legally retain rights of authorship in a work not registered for
copyright and for which the work has been released publicly without
proper copyright notice.

However, other sections of the Copyright Act (and other tort laws)
would likely govern the issue of whether or not viral code is proper
"copyrightable subject matter" in the first place.  It is not very
probable that the Register of Copyrights would allow the registration
of viral code.  On the other hand, they seem determine that "in
accordance with the provisions of this title [Title 17 - Copyrights],
the material deposited does not constitute copyrightable subject
matter or that the claim is invalid for any other reason," and could
thereby refuse registration. (see section 410, subsection (b))

Just a few thoughts to further muddy the waters.

QUESTIONS:

1.  Why on earth would law-breakers expose themselves to the arms of
    justice by attempting to enforce viral code copyrights?

2.  If viral code is really able to be legally sanctioned by Title 17,
    can anti-viral authors freely write programs without infringing
    the "derivative work" right of the viral code copyright owner?
    (see Copyright Act definition of derivative work and section 106,
    subsection (2))

Stuart Milligan
Drake Memorial Library
SUNY at Brockport
Brockport, NY  14420

[phone]

------------------------------

Date:    15 Feb 90 00:00:00 +0000
From:    "David.M..Chess" <[e-mail]>
Subject: re: Universal Virus Detector

> VDOS pseudo-executes the program, checking for
> every possible outcome and attempts to write to disk.

Unlikely to be practical, I'm afraid?  For instance, if the program
waits for user input, or looks at the time or date, or reads from a
file (I can't think of -any- program offhand that doesn't sometimes do
at least one of these), the pseudo-executor would have to
pseudo-execute a separate instance of the program for every possible
input/time/data-item.  Not likely to finish within the life-expectancy
of the user!

DC

------------------------------

Date:    15 Feb 90 00:00:00 +0000
From:    "David.M..Chess" <[e-mail]>
Subject: re: AIDS program (PC)

The PC Cyborg AIDS diskette did include a sizeable program (AIDS.EXE)
containing lots of code and data for administering a questionaire and
giving AIDS-related advice.  I can't speak for the *quality* of that
advice, but the program was definitely non-trivial.  The only negative
thing I know for sure about it was that it refused to run unless the
nefarious INSTALL.EXE had been run first.  (Of course, there may once
have been some non-nefarious INSTALL program that also set whatever
flag AIDS.EXE looks for.)

DC

------------------------------

Date:    15 Feb 90 20:46:13 +0000
From:    [e-mail] (Lambert Meertens)
Subject: Re: The AIDS "Trojan" is a Copy Protection System

[e-mail] writes:
)
)  1) The AIDS disk did not have copy protection at all.  [...]
)  2) The disks were unsolicited.  [...]
)  3) The market to which the disks were targeted was especially sensitive.
)     [...]

In addition, it may be pointed out that a user who wrote out a check and
mailed it to Cyborg, and only then used the program, was equally at risk.
I do not understand how anyone can seriously doubt that this was a scheme
for obtaining money in an unethical way.

- --Lambert Meertens, CWI, Amsterdam; [e-mail]

------------------------------

Date:    Thu, 15 Feb 90 18:49:15 -0500
From:    Mike Kapfer TSG <[e-mail]>
Subject: Pakastani Virus (PC)

  One of our student labs seems to have been infected by the Pakastani
virus (aka. BRAIN).  Many of the student's disks sampled, have also
been infected.  We are currently assessing the scope of this infection
on our campus.  We do not believe that our NOVELL networks can be
infected since this virus is a boot sector infection.  I would
appreciate any information about this virus.  Please mail to me
directly.  Thank you.

Michael Kapfer: Old Dominion University: Norfolk, VA: USA: [phone]

------------------------------

Date:    Wed, 14 Feb 90 17:23:26 +0000
From:    [e-mail] (Spenser Aden)
Subject: Re: The ethics of virus eradication

[e-mail] writes:
>My questions are these - what should I have done? Kept the infection
>secret? Are computer viruses a Social Disease? Are we physicians who
>are supposed to swear some form of Computerized Hippocratic Oath of
>confidentiality? Or, do we paint a Scarlet-V on the heads(or
>terminals) of those unfortunate ( careless enough) to become infected?

Your action seems completely reasonable.  Why in the world would
anyone without something to hide want to have it not be known that a
virus was loose?  While this person may have been embarrased by the
fact that people could figure out that he was the one who introduced a
virus, it's certainly more important to stop the spreading than simply
preserve his own reputation.  And after all, he didn't deliberately do
it (I presume), so why not try to stop it?

I don't think that painting the Scarlet-V on his character is proper,
but then I don't think that is what you intended with your e-mail.
Whether the e-mail did or not, though, is up to personal opinion
(IMHO).  But if you tried as best you felt you could to preserve his
anonymity, then I feel this was a correct and reasonable response to
the infection.

- -Spenser

- --
S. Spenser Aden                  | This may have been a test of the emergency
Ferranti International Controls  | flame-throwing system.  Had this been an
[e-mail]              | actual flame, you would have been instructed
Only my opinions, not Ferranti's.| where to follow-up.  This was only a test.

------------------------------

Date:    15 Feb 90 10:30:27 +0000
From:    [e-mail] (Mikel Lechner)
Subject: Re: AIDS Trojan - self protection

woodb!scsmo1![e-mail] writes:

 >> 1.   That all of the users who were adversely affected by this
 >>      supposed trojan either (a) did not read the license
 >>      agreement for the program which they were installing, or (b)
 >>      they read it and ignored it.  Either way, they must accept
 >>      the consequences.  The installation instructions first step
 >>      tells you to read the agreement on the reverse of the sheet.

Or perhaps they read it and did not understand its implications.

 >  I agree, this is the most common practice.  You get this great
 >software and you want to see it RIGHT NOW!  Well, one DOES need to
 >read those agreements and take them at face value.

In any case a license is a contract and contracts are governed by
contract law.  Just because something is stated in a contract does not
make it legally binding.  The contract must abide by contract law.
For example a copyright must meet certain qualifications to valid.  It
must use the word "copyright," it must appear in an obvious place
(where it cannot be overlooked), and it must state what rights are, or
are not, granted.  If if fails these requirements it is not a valid
copyright.

For example, let's say I include a copyright in a program I write in
some obscure place in the program.  Someone then copys and uses my
program in a way forbidden by my "copyright" notice.  Since my
"copyright" was not obvious (to a reasonable person) it would be
invalid.  The same logic applies to license agreements.

To state in a license agreement that using a product without paying
for it will cause intentional damage most certainly violates the law.
Therefore such a license agreement is not valid period!  To say the
program will not function without payment is not illegal, and
therefore is valid in a license agreement.  A self-destructing program
is simply making itselft non-functional.  The AIDS trojan willfully
destroys another person's property.  These seem like quite different
situations to me.

- --
                                If you explain so clearly that nobody
                                can misunderstand, somebody will.
Mikel Lechner
Teradyne EDA, Inc.              UUCP:  [e-mail]

------------------------------

Date:    16 Feb 90 06:12:51 +0000
From:    [e-mail] (Bernard Littau)
Subject: Re: Undetectable Virus (Mac)


[e-mail] (Betty Harvey) writes:
>       I have seen two Macintoshes that have a virus that I can't seem
>to recognize.  I have run Disinfectant 1.6 because I thought it was the
>WDEF virus that I have been reading about but disinfectant didn't find
>anything abnormal.  I have also ran several other virus eradicaters and
>they didn't recognize anything out of the ordinary.
>
>                       Symptoms:
>
>       The system file increases in size and the date changes
>       each time the system is rebooted.  One system file was
>       2 meg long before all application program ceased to work.
>
>       Applications unexpectedly stop.
>
>       The system hoses up occasionally when going to the printer.
>
>Is anyone aware of any new viruses or what I might be dealing with.
>We had a massive outbreak of Scores and nVir about 1 year ago, but
>have had fairly healthy machines since then.

I have experienced similar behavior on some of my Macs.  I usually
found a system resource was trashed.  Rezdet, part of MPW, would
pinpoint the offending resource.

I now leave the system locked.  This prevents the problem
I was having, but also prevents other things, like changing the
desktop pattern.

I attributed the problem to programs crashing under MultiFinder.

To the best of my reccollection, the vers resource was the one usually
trashed.  Sometimes deleting the bad vers would remove the problem and
the system's growth.  At other times, the system would need to be
restored from backup.

I now lock system as a matter of course.  Can anyone come up with a
reason why this would be a bad idea?


Bernard Littau    VM Radiological Sciences        Telephone: [phone]
                  School of Veterinary Medicine   Internet:  [e-mail]
                  University of California        BITNET:    vmrad@ucdavis
                  Davis, CA 95616                 UUCP: ucbvax!ucdavis!vmrad

------------------------------

Date:    14 Feb 90 12:25:56 +0000
From:    [e-mail] (JM Ivler)
Subject: Re: The AIDS "Trojan" is a Copy Protection Systemy

munnari!mqccsunc.mqcc.mq.oz.au![e-mail] (Ian Farquhar) writes:
> "Read this license agreement carefully.  If you do not agree with the
> terms and conditions stated below, do not use the software, and do not
> break the seal (if any) on the software diskette..."
>
> ...
>
> End quote.
>
> This is not a trojan: it is a COPY PROTECTION SYSTEM.

If that is the case, the proper thing for his attorney to do is:

1) don't fight extradition
2) file an immediate lawsit for specific damages in the courts

The suit shaould name anyone who printed anything in anyway that
explained on how to "clean" the system of the protections. The damages
are (# of disks distributed)* US$378 . This is based on the fact that
there is no idea on how many people read the articles that told how to
"break through the copy protections" but that all owners of the disks
have the capability to do so.

Then there is the damage to the "good name" of PC Cyborg... I would
hate to be one of the publishers of a magazine that told people how to
"get rid of the AIDS trojan."

This has been a very expensive lesson.

jmi   [e-mail]

------------------------------

Date:    Fri, 16 Feb 90 05:08:29 +0000
From:    [e-mail] (Alan D Danziger)
Subject: Re: Virus Buster (PC)

Well, I got an emergency call from a friend of the family this
evening, and I was wondering if anyone has heard anything about the
problem she had...
  She's working on a Mac SE, 20 meg Apple drive, system 6.0.4/finder
6.1 (I think, its the 107K version that comes w/ 6.0.4), and after
about 2 months of using it, calls me with this problem:

    The Mac's trash can icon has disappeared, and there's a message at
the bottom of the screen, 'based on a program by Encore Systems' or
something close to that...  Also, the menus are messed up: File has
'New folder' and 'Close', edit, view, and the apple menu are fine,
Special had no entries originally, and there were 3 extra menus: one I
can't remember, a 'style' menu, and a 'attrib' menu.

    I had her replace the finder and the system files separately in
the system folder, checking for invisible files with Disktools II (but
I didn't recognize any), and it still didn't work.  FInally I had her
remove system and finder into separate folders, and rename the system
folder to 'old sys' and copy the system folder from a locked System
Tools floppy, and when she rebooted the problem remained.

        If you have any ideas as to what this might be from, PLEASE
respond ASAP via Email (and posting here if you want) because she is
slightly frantic, and I can't drive 250 miles just for that...  She
will be calling me Sunday night or Monday morning for an answer, so...

        Thanks in advance,
                -=Alan
                [e-mail]
                [e-mail]

------------------------------

Date:    16 Feb 90 06:06:39 +0000
From:    khijol![e-mail] (Ed Carp, aka Mr. Ed the talking horse...)
Subject: Re: The ethics of virus eradication

[e-mail] writes:

>Well, that didn't work. The faculty member was extremely angry about
>the E-mail message. I did mention the type of program that was the

What's the guy's problem?  So he got bit?  So what?  People get bit by
the virus all the time; it's not a big deal from the social
standpoint.  What's he think -- someone's going to point at him in the
hall and giggle?  Sounds like the guy has an extreme personal problem
to me.

I think you took a prudent necessary step to protect the users of the
computer system.  The faculty member that complained is looking at
things from his own personal (read: ego) standpoint.
- --
Ed Carp                 N7EKG/5 (28.3-28.5)     uunet!cs.utexas.edu!khijol!erc
Austin, Texas           [phone]          "Good tea.  Nice house." - Worf
Opinions expressed are mine. Copyright 1990 Edwin R. Carp. All Rights Reserved.

------------------------------

Date:    Fri, 16 Feb 90 10:19:48 -0500
From:    Mike Kapfer TSG <[e-mail]>
Subject: Ohio Virus: Old Dominion U (PC)

  As part of the procedure to erradicate the BRAIN virus from the
academic community at Old Dominon, we are requiring that all students
have their diskettes scanned before using our labes.  During one of
these scans - the OHIO virus was discovered on a student's disk.  I am
presuming that the OHIO virus is similar to the BRAIN virus but ...
any information on the OHIO virus would be appreciated.  Thanks

Michael Kapfer: Old Dominion University:  Norfolk, VA: USA: [phone]

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Tuesday, 20 Feb 1990    Volume 3 : Issue 45

Today's Topics:

Upcoming Virus Conference
BRAIN, OHIO, SCANV57 (PC)
The 1559 virus (PC)
Disinfectant 1.6 (Mac)
Re: Many WDEF reports (Mac)
Mosaic and FontFinder Trojans (MAC) -- Update #2
Re: UNIX discussions?
McAfee's SCAN makes National News in Canada
Re: The AIDS "Trojan" is a Copy Protection System
Re: Identification strings
Re: There is no Ultimate Anti-Viral Solution!
Government Newsletter
Re: CMOS viruses? Nonsense! (PC)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

---------------------------------------------------------------------------

Date:    Fri, 16 Feb 90 12:34:00 -0500
From:    [e-mail]
Subject: Upcoming Virus Conference

The 3rd Annual Computer Virus Clinic will be held on March 14-15
(Wednesday-Thursday) at the World Trade Center in New York City.
VIRUS-L followers may be interested to note that V-L moderator, Ken van
Wyk, will be one of speakers, along with such other virological
luminaries as Drs.  Harold J.  Highland and Fred Cohen.

The sponsor is the DPMA Financial Industries Chapter.  Information is
available via [phone] (voice!), or by mail to

          Box 894
          Wall Street Station
          New York, NY 10268

I understand 8 or so products will be shown, for those who like to see
the way things work, and there will be a reception at Windows on the
World after the sessions the first day.  There will be two session
"tracks," nominally Management and Technical (from what I've heard,
these names are misleading), and while the sessions will be more PC than
MAC oriented (when such a distinction applies; for example, the "How Do
You Test an Anti-Virus Product?" talk will cite DOS features and program
tools), MAC areas will be receiving adequate treatment.

In spite of one speaker known for his views that viruses are a fad, and
some speaker/topic pairs that seem to be at every virus conference (and
who will therefore sound very familiar to those who regularly go to
these things), it seems to be a potentially interesting meeting, more so
because of the potential of an open panel discussion (panelists as yet
unspecified) scheduled for the second day.

All "facts" above I have only heard from the man setting up the
conference; I've seen nothing in writing.  The 800 number should yield
yield more current information (and, I presume, information on travel,
lodging, etc.).

------------------------------

Date:    Fri, 16 Feb 90 10:35:39 -0500
From:    Mike Kapfer TSG <[e-mail]>
Subject: BRAIN, OHIO, SCANV57 (PC)

  Last night we discovered the Brain virus in one of our student labs.
As a precautionary measure, we now require that all students get their
diskettes certified by Computer Services before using them in our labs.
While scanning these disks, we have also discovered the OHIO virus.
  Now, for the clincher.  If the virus is active (The Brain virus),
SCANV57 will NOT discover it when it does it's memory check.  Nor will
it discover it in the BOOT sector of the infected diskette.  When the
machine is booted from a "clean" floppy, SCANV57 identifies the virus.
My question is: what is the point in scanning memory for a virus if it
will not pick up an active virus?

Michael Kapfer: Old Dominion University: Norfolk, VA: USA: [phone]

------------------------------

Date:    16 Feb 90 19:51:00 +0700
From:    [e-mail]
Subject: The 1559 virus (PC)

Hi!

Recently, the subscribers of VALERT-L received an uuencoded file which
(as the sender said) was infected with a new virus. Of course, sending
an infected file to a public (and non-moderated) forum is a big
mistake, but I won't emphasize this here.

[Ed. Absolutely agreed, and the sender has been told of his error.
Unfortunately, most of the copies had already been sent out by
then...]

Personally, I received at least 3 more messages, which warned me that
I *have* to delete this file and not to uudecode it. However, since
I'm an antivirus researcher, I couldn't resist to the temptation and
"test" the virus --- of course in a "safe" environment.

It turned out that the environment was too safe... I worked on a
computer with physically disabled hard disk.  I booted from a floppy,
containing only the operating system (PC-DOS 3.30), the infected file,
MAPMEM (a public-domain utility) and ANTI4US --- an interrupt
monitoring program --- much like FluShot+ but with much worse
interface.

I started the interrupt monitor and executed the infected file. Then I
executed MAPMEM. I wanted to (1) see if the virus can be "seen" in
memory with this utility and (2) confirm that the infected file is
"infective" i.e., contains  really  a  virus.  Of  course,  MAPMEM
didn't saw the beast.

Then I cold-rebooted from a new clear and write-protected diskette and
inspected the MAPMEM.COM file. Well, it wasn't infected at all! I
decided that I have received a damaged file and sent a message to the
author to send me a new file, consisting only of NOPs, infected with
the virus. He did so.

Further investigations showed that:

        - If I load ANTI4US and then run an infected program, the damn
          thing does not spread --- it ever does not try to infect
          files.

        - However, if I first run an infected program and then
          ANTI4US, the beast tries to spread (which is detected by
          ANTI4US) --- and of course infects ANTI4US.

At that point I was convinced that it is really a virus. Now I'm
trying to disassemble it and to write an antidote. Here is what I know
for the moment (without any warrant!):

        - The virus is memory resident. It installs itself in the
          memory at address 9800:0000. I couldn't find where (and if)
          it checks for the memory size.

        - The virus is 1554 bytes long, but may add more bytes (up to
          1569 I think) to the infected files.

        - Files are infected when they are executed (*not* when
          copied).

        - Both *.COM and *.EXE files can be infected.

        - COMMAND.COM can be infected --- if it is executed.

        - Files are infected only once.

        - The ReadOnly attribute won't help (you already guessed
          this :-) ).

        - The virus has its own critical error handler. Therefore an
          attempt to infect a file on a write-protected diskette won't
          display the usual "Abort, Retry, Ignore? " message.

        - The size of the infected files is such that always (SIZE mod
          16 == 2).

        - Only *.COM files greater than 1000 bytes will be infected. I
          couldn't find if there is a limit for the *.EXE ones.

        - The first 32 bytes of the *.COM files are overwritten. The
          original 32 bytes can be found at offset [14,15]*16+1015
          from the beginning of the file. Here [14,15] means the
          contents of the word at offset 14 (decimal) from the
          beginning of the file. I'm still trying to find how the
          virus infects *.EXE files.

DAMAGE:

        - The virus intercepts the WRITE function call (AH == 40h) of
          INT 21h.  If the month of the current date is 9 or greater,
          and if the write is on file handle > 4 (i.e., it is a "true"
          file, not stdin/out/err/aux/prn), then the address of the
          memory chunk which has to be written, is increased by 0Ah.
          This leads to garbage being written.

I haven't finished my work with this virus, but it's getting late and
I have to leave. Therefore, I decided to post what I know. Please, if
anyone knows more about this virus, send info to the forum too.

[Ed. As already noted, SCAN v 58 has been modified to detect this virus.]

                        Vesselin Bontchev
                (a Bulgarian antivirus researcher)

------------------------------

Date:    Fri, 16 Feb 90 14:52:38 -0500
From:    <[e-mail]> (Eric Rowan)
Subject: Disinfectant 1.6 (Mac)

      I realize that Mr. John Norstad just released Disinfectant 1.6
and has again announced that Disinfectant 2.0 is forthcoming, but has
he or his colleagues announced WHEN we can anticipate its release?
I'msure everybody is working hard on releasing it quickly, but I'm
just wondering what the timetable is.
      I also wanted to publically thank Mr. Norstad and his associates
for creating Disinfectant, for making it free, and for keeping it
up-to-date.  For all of that and more...THANKS!

 Eric Rowan
 Southern Illinois University at Carbondale
 Computer Learning Center 1
 Faner 1027
 Carbondale, IL  62901  *USA*

------------------------------

Date:    16 Feb 90 19:57:20 +0000
From:    "David N. Schlesinger" <[e-mail]>
Subject: Re: Many WDEF reports (Mac)

[e-mail] (David.M..Chess) writes:
> Curious as to why we're seeing all these WDEF reports, and not similar
> numbers of reports of other widespread viruses.  Has it just become a
> tradition to report WDEF on VIRUS-L, or is WDEF better at spreading?
> If the latter, does anyone have a good feeling for what about WDEF
> makes it so (um) virulent?  DC

I believe that one of the reasons for the swift spread of WDEF is that it
doesn't require the Launch of a program to infect a target system.  WDEF
spreads simply by inserting an infected disk into an uninfected machine
(clever bit of design work there, actually...)

Also, WDEF is not recognized by much of the current generation of "Virus
Protection" software, e.g. SAM (versions prior to 1.4), Virex (versions
prior to 2.3), etc.  Many people seem to have the impression that once
they've installed any version of a virus catcher, they're protected for
life...

===========================================================================
          David N. Schlesinger   || "There's a word for it: words don't
          The Wollongong Group   ||  mean a thing.  There's a name for it;
Internet: [e-mail]          ||  names make all the difference in the
POTS:     415/962-7219           ||  world..." -- David Byrne
===========================================================================

------------------------------

Date:    Fri, 16 Feb 90 17:11:42 -0700
From:    Peter Johnston <[e-mail]>
Subject: Mosaic and FontFinder Trojans (MAC) -- Update #2

10 Feb 1990, the trigger date for these trojans, has come
and gone. I have heard no reports of further attacks by
either of these trojans.

These nasties would appear to be fairly localized based on
the lack of additional attacks. But the speed with which the
warning was spread and the general lack of panic suggests
that we have a very effective tool with which to combat
these electronic vandals.

I think that everyone who helped relay the warnings (and
from the comments and queries I received, the warning was
truly spread worldwide) deserves a hearty "Well Done".

My thanks to all those who assisted and "passed the word".
If you hear of any future sightings or attacks from either
of these trojans, I would appreciate it if you would contact
me directly...

 - - - - - - - - - - - - - - - - - - - - - - - - - -
 Peter Johnston, Senior Analyst,
 University Computing Systems, 352 - GenSvcBldg,
 The University of Alberta, Edmonton, Alberta, CANADA  T6G 2H1
 Voice: 403/492-2462    EMAIL: [e-mail]
   FAX: [phone]
 - - - - - - - - - - - - - - - - - - - - - - - - - -

------------------------------

Date:    Fri, 16 Feb 90 20:20:15 +0000
From:    [e-mail] (Peter da Silva)
Subject: Re: UNIX discussions?

There is a UNIX security list that discusses the subject of security holes
in UNIX. Mail to [e-mail] for more information.

[Ed. I also invite more UNIX discussions here on VIRUS-L/comp.virus.]

 _--_|\  Peter da Silva. [phone]. <[e-mail]>.
/      \
\_.--._/ Xenix Support -- it's not just a job, it's an adventure!
      v  "Have you hugged your wolf today?" `-_-'

------------------------------

Date:    Fri, 16 Feb 90 23:38:42 -0500
From:    Peter Jaspers-Fayer <[e-mail]>
Subject: McAfee's SCAN makes National News in Canada

Seems Parliament hill was hit by the Stoned virus today.  News clip
showed someone at a PC, voice over "All computers are now being
regularly scanned", and what should pop up on the screen but the "No
viruses found ...etc" that McAfee's SCAN program displays when done.
Sadly, no credit was given in the broadcast.

/PJ                                                 [e-mail]
                     -------------------------------
Computers are not intelligent. They only think they are.

------------------------------

Date:    Fri, 16 Feb 90 06:38:05 +0000
From:    wolves.uucp![e-mail] (Gregory G. Woodbury)
Subject: Re: The AIDS "Trojan" is a Copy Protection System

munnari!mqccsunc.mqcc.mq.oz.au![e-mail] (Ian Farquhar) writes:

>       [much tedious commentary from the "license" deleted]

>This is not a trojan: it is a COPY PROTECTION SYSTEM.  The
>consequences of using the program without paying are quite adequately
>laid out in the license, which apparently has not been read.  It warns
>quite clearly that:

>a)   You should not install this program unless you are going to
>     pay for it.

        With *NO VALID ADDRESS* to send the "license fee" to?
        And with no way of having the program be informed that
        the fee has been paid?

>b)   The program contains mechanisms that will ensure that the
>     terms of this license agreement will be followed.

        At a *random* interval, without providing any means of
        checking to see if a validation (obtained by paying the
        "license fee") exists?

>c)   That these mechanisms will affect other programs on the hard
>     disk.

        Yeah, by blowing away the whole system!

>I am led to make the following conclusions:

>1.   That all of the users who were adversely affected by this
>     supposed trojan either (a) did not read the license
>     agreement for the program which they were installing, or (b)
>     they read it and ignored it.  Either way, they must accept
>     the consequences.  The installation instructions first step
>     tells you to read the agreement on the reverse of the sheet.

        Several companies sent off the license fee *AS DIRECTED*,
        They waited several weeks for a response, and getting none,
        decided to use the programs - 'cause they *DID* pay the
        "license fee"  --- it still blew away their computers!

>2.   That the people who have been harping on at length about
>     this trojan did not bother to read the license agreement
>     either.  I am left wondering if the "excitement" of this
>     horrible "trojan" prevented them using some elementary logic
>     to ask if the program may be something else.

        Incorrect - several did read the "license" and abide by its
        terms -- the creator of the program did not abide by his
        (implied) end of the deal by insuring that the program
        *ONCE PAID FOR* would not harm the users system....

>3.   PC Cyborg laid out the consequences quite plainly in the
>     license agreement.  It is a debatable point whether PC
>     Cyborg would have sent the "defusing" program for the time
>     bomb that this program installs, though the US invasion
>     would have defeated any attempt to do this (the invasion was
>     doubtless more illegal than this program).

        Also Incorrect!  The US Intervention in Panama did not disrupt
        the mail system nearly as much as it did other aspects of life
        in that place (btw - political commentary should be sent
        to talk.politics.misc ;-).  There is no evidence that there
        was ANY ATTEMPT to collect the fees sent to that address,
        nor is there any evidence that there is/was an authorizor
        program to provide validation of the payment of the "license
        fee"

>4.   That the people hurriedly disassembling the program actually
>     committed a breach of the license agreement, and are liable
>     for legal action from PC Cyborg.  Equally, copying of this
>     program is as illegal and is as much piracy as copying any
>     commercial program.

        In as much as there is *NO LEGAL ENTITY* as PC Cyborg,
        there is NO LICENSE.  A license is a contract.  There must
        be two legally valid parties to a valid contract.  There is
        no "PC Cyborg" in a legal sense, therefore, there is no
        binding license.

>I am stunned at the sheer volume of pointless garbage that this
>program has generated, and it makes me seriously doubt any other
>information received from these "experts".  I would also point out
>that self-destructing programs are not new, but one has never caused
>such an outcry before.

        I fail to comprehend your characterization of the posting on
        this issue as "garbage".  Given the points that I made above in
        relation to your particular thesis, I would be interested in
        knowing if you have changed your opinion given the new information.

>If the author of this program is convicted, it will be the first
>conviction ever for the hidious crime of writing a copy protection
>system, and will be one of the biggest farces of justice ever
>witnessed.

        Copy protection scheme?
        Please be realistic here, to me it is obvious that this
        is a blatant case of electronic/software terrorism.
- --
Gregory G. Woodbury
Sysop/owner Wolves Den UNIX BBS (919 493 7111), Durham NC  (also)
System Programmer/Manager  Center for Demographic Studies, Duke University
UUCP: ...dukcds!wolves!ggw   ...dukeac!wolves!ggw           [use the maps!]
Domain: [e-mail]  [e-mail]  [e-mail]
[The line eater is a boojum snark! ]           <standard disclaimers apply>

------------------------------

Date:    18 Feb 90 15:36:19 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Re: Identification strings

[e-mail] writes:
>And what if virus-scanning programs are written in such way that they
>search the identification string only in the place it has to be ---
>not in the whole file?

Well, some anti-virus programs do this.  In general they are faster
than other programs, but when a new variant of a virus appears, they
are unable to detect it.  But you are right - at least they would not
report other anti-virus programs as infected.

- --
Fridrik Skulason   -   University of Iceland, Computing Services.
[e-mail]        Technical Editor, Virus Bulletin (UK).

------------------------------

Date:    18 Feb 90 15:32:21 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Re: There is no Ultimate Anti-Viral Solution!

[e-mail] (Robert I. Eachus) writes:
>infeasible.  The third group is problems which have been proven
>insoluble using any type of solution, imaginable or otherwise.  This
>group includes problems like the Post Correspondence Problem, the
>Halting problem, and universal virus detectors.

Here we go again....

The Halting Problem and UVD problem are indeed unsolvable on a Turing
machine, but they are theoretically (but not in practice) solvable on
a "real-vorld" computer.

There are some limitations, however - the machine needed to solve the
problem must be many orders of magnitude larger than the machine the
program is running on.

- --
Fridrik Skulason   -   University of Iceland, Computing Services.
[e-mail]        Technical Editor, Virus Bulletin (UK).

------------------------------

Date:    Sun, 18 Feb 90 20:54:28 -0500
From:    woodb!scsmo1![e-mail]
Subject: Government Newsletter

Call for Government Employees for a Government On-line Newsletter.

I am currently making a list of government employees who are interested in
contributing and to receiving an on-line newsletter.

This will be an informal unofficial newsletter to discuss problems and
solutions within government computing.  Some  of the issues  I wish to
include as topics are:

FTS2000
Computer Security
GSA
FOCUS contract..
AFCAC contract...
Other Government contracts...
Where to find computer 'deals'
Virus breakouts and how to stop them.
Chat from vendors...
Hardware/software problems - solutions.
TCP/IP logins and where to find needed files.  Also for those who
do not have TCP/IP maybe we can setup a re-distributor system.
Interviews with AT&T and other computer experts.
etc..

This is open to all Government employees of any and all systems and
OSs.  Because this is on-line there will be no 'paper' mailings due to
cost.

If interested contact me at:

Don Ingli
USDA/SCS
FTS 276-5344
314 875-5344

Remember that this is unofficial and is done on my own time....
Also, no sensitive material will be published or accepted.

- --
 DON INGLI-United States Department of Agriculture - Soil Conservation Service
 INTERNET: scsmo1![e-mail]    PHONEnet: 314!875!5344
 UUCP(short): uunet!scsmo1!don        UUCP(long): uunet!mimsy!woodb!scsmo1!don
              These are my opinions. I represent myself.
   Who do you think you are, Bjorn Nitmo?  David Letterman '90 Catch Phrase

------------------------------

Date:    19 Feb 90 02:04:46 +0000
From:    rpp386.cactus.org![e-mail] (Woodrow Baker)
Subject: Re: CMOS viruses? Nonsense! (PC)

[e-mail] writes:

> >this one lives in the setup-memory (CMOS) that was backed up by the
> >computer battery.  All the infected diskette can be reformatted and can
> >plausible and that's why I decided to hear from experts' opinion on
> >the net.  Since today's AT usually uses CMOS memory, this looks a
> >serious problem.
>
> Nonsense! There are only 64 bytes there and only the half of them are
> not used (these at offsets 11h, 13h, 1Bh-2Dh, 34h-3Fh). And even if
> someone is smart enough to write such a small virus (which I claim to
> be also impossible on 80x86 based computer), these bytes are not
> directly addressable. This means that you cannot *execute* the code
> which resides in them. You have prior to extract it (using some IN and
> OUT instructions). But the code, which will be able to do this *ought*
> to reside somewhere else.

True and false.  You would have to extract them with in/out
instructions BUT, you could store some code there, enough to do
damage, say a jump to format a track....It is small enough, or perhaps
a decryption routine, like the 8 code wonder in the 4096 virus, or....

BTW, did you know that you can download code from the KEYBOARD?  IBM
uses it apparently to generate some test code, and squirt it into
memory.  Now, granted, one would have to burn the nasty into rom in
the keyboard, but some one could convievably do that at the factory.
I think that the POS queries the keyboard, I'd have to go back and
look at the tech ref manual.  It might even be possible, to
dissasemble the keyboard roms and find some backdoor that you could
use to store code.  Not much use, but has at least the potential of
the cmos chip...

Cheers
Woody

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Wednesday, 21 Feb 1990    Volume 3 : Issue 46

Today's Topics:

AIDS Copy Prtection System
Copyright restrictions
WDef problems - it doesn't go away (Mac)
Effects on checksum programs (PC)
New variant of Cascade/1704 (PC)
F-PROT news (PC)
Certus (FoundationWare)
Gatekeeper 1.1.1?
WDEF details (Mac)
SCAN and the Brain (PC)
RE: Disinfectant 1.6 (Mac)
RE: Trojan Horses != Copy Protection

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

---------------------------------------------------------------------------

Date:    Mon, 19 Feb 90 16:22:43 -0500
From:    munnari!mqccsunc.mqcc.mq.oz.au![e-mail] (Ian Farquhar)
Subject: AIDS Copy Prtection System

My article about the PC Cyborg AIDS Copy Protection System has
caused quite a bit of discussion, and I would like to publicly
reply to many issues that were raised.

1)   FREE MARKET

Many writers pointed out that the program itself was garbage, and
justified their position (that it was a Trojan) with the argument
that the money for the program was far too much and thus the
program was an extortion racket.

Being an Australia, I am used to being charged extortionate
prices for software by both amateurs and professional companies.
The point that must be made, however, is that in a free market
economy the supplier can charge what they like.  The idea is that
supply and demand will weed out the excessively priced garbage
from the reasonably priced quality items.

Using this principle, PC Cyborg can charge what they like.  This
is not an effective argument either way.

2)   THE ABSENCE OF THE REGISTRATION DISKS

It is presumed that PC Cyborg would have sent the defuser program
on receipt of the registration fee.  Many people have pointed out
that this did not happen.  I imagine that the US Military rolling
into Panama may have had something to do with that.

3)   THE DEFINITION OF COPY PROTECTION

Copy protection, by my definition, is a device, system or
technique whereby the copyright holder can guarantee that the
terms of the license are followed.

Let us take the example of the color-bar system.  The color bar
is a small sheet or sheets of pages containing a series of codes
that are matched to colors.  The program, when started, asks the
user what color is found on page 2, row 4 column 19.  If the user
answers correctly, then the program proceeds.  If not, the
program usually asks a couple of times more, then takes action.

By the definitions of many of the writers, this would not be a
copy protection system (because it allows you to copy the disk).
However, it maintains the license agreements as only the person
in possession of the color-bar sheet can run the program, and it
is hard to cheaply copy a colored sheet.

The AIDS CP System was simply an extension of this.  It allowed
copying of the distribution disk, and it allowed backing up of
the hard disk.  All it did was to ensure that people who were
unregistered (and which were, I hasten to add, involved in a
criminal activity) would have a lot of trouble.

As for the concept of the user having legal control over what was
deleted from his/her hard disk, I cannot see this as a problem.
Multi-user systems have traditionally provided mechanisms for the
superuser to control the user's files with far more privileges
than the users themselves.  This has never, to my knowledge,
caused any legal problems.

4)   INAPPLICABILITY OF US LAWS

Many correspondents have quoted US laws and precedents at great
length.  These are totally irrelevant, as the license agreement
prohibited importation into the US.

5)   PRESUMPTION OF INNOCENCE

Under British law, there is a concept called the "presumption of
innocence".  Put basically, someone is innocent until they are
proven guilty.  It would be nice to know that this basic concept
is still followed, though I really do have my doubts.

If I were the defense lawyer with access to this newsgroup, the
first thing that I would have done is to take all of the relevant
articles that have appeared, and present them as evidence
prejudicial to the fair conduct of the trial.

6)   CONCLUSION

I am left wondering about the motives of many of the writers.
There seems to be a fanatical, indeed almost religious zeal to
see anyone concerned with the generation of viruses and Trojans
convicted irregardless of the evidence (or its lack).

There certainly seems to be a panic mentality at work here - the
illusion that quick action is necessary regardless of the
advisability of that action.  There also is a strong reluctance
to change an opinion in the light of new evidence, which is very
worrying indeed.

I have always maintained that computer security experts and
employees of the intelligence services share many things in
common, primarily the huge and quite unwarranted sense of
paranoia.  This whole discussion has only strengthened this view.


Disclaimer:  My opinions are my own.

Ian Farquhar                      Phone : [phone]
Office of Computing Services      Fax   : [phone]
Macquarie University  NSW  2109   Also  : [phone]
Australia                         Telex : AA122377

ACSNet [e-mail]  [e-mail]

------------------------------

Date:    Sun, 18 Feb 90 16:29:00 -0500
From:    IA88000 <[e-mail]>
Subject: Copyright restrictions

When an item like a computer program is first created, it is my
understanding that it is immediately copyrighted. It is NOT REGISTERED
with the Copyright office until such time as you pay the ten dollar
fee and file the appropriate forms.

However, in the past some software has been released with a
copyright notice similar to:

XYZ DATABASE PROGRAM
Copyright 1987 as an UNPUBLISHED work

I have read the manual the copyright office will send you and find
that this is a legal way to copyright a program.

The questions are:

1) Was the AIDS program copyrighted? Did anyone bother to check to
   see if an application was filed?

2) Assume for a moment that it was copyrighted. Can the copyright
   be enforced and can the author collect damages?

3) Does the fact that a program appears to be and may be capable
   of damaging a disk allow give anyone the right to violate a
   copyright?

If you feel that statement three allows someone to violate a
copyright, consider this for a moment.

One of the major copy protection companies uses a scheme which
encrypts one or more tracks of a hard disk drive when someone
installs a copy protected program.

Until such time as the copy protected program is removed the
encrypted tracks are useless,(in fact some people may even call
them damaged) to any program other than the copy protected
program which was installed.

It really is the same thing. If a program is copyrighted, the
fact that it may be a virus, a trojan horse or a legitimate copy
protection package does not imply that it is fair game for some
people to hack apart and provide information about at will.

If in fact the same discussions and information were disclosed
regarding a major company in the spreadsheet market, that company
might (and has in the past) taken legal action against people who
disclosed information or transfered copies of the program.

Do not get me wrong, I think what was done by the creator of the
AIDS trojan was wrong, and he/she should be punished. However the
assumption that just because a copyrighted program happens to be
a virus or a trojan, and as such copyright law may be ignored is
also wrong.


*****************************DISCLAIMER*************************

 The views expressed are my own! I do not speak for, nor do I
 represent any other person, company or educational institution.

*****************************DISCLAIMER*************************

------------------------------

Date:    Mon, 19 Feb 90 01:22:00 -0600
From:    "Paul Duckenfield (Consultant, User Services)" <[e-mail]>
Subject: WDef problems - it doesn't go away (Mac)

        As I mentioned in a previous message, we have had (and
probably still have) WDef B running about Carleton College's Macintosh
community. So far, it appears to have restricted itself to the public
labs and has yet to break into the general computing community. I have
found that RAM disks on public Macintosh Pluses have greatly limited
the spread of the virus because no single machine can have the virus
for very long (invariably, we have to reboot each machine every couple
of hours). Even if a RAM disk is infected, it is unlikely to infect
many other users since the RAM disk will be reset in a matter of
hours. This is our first line of protection. At the moment, we are
redoing the master RAM startup disks so that they have WDef protection
as well. That will be our second line of defense. Our final line of
defense is (hopefully) the responsibility of the individual user to
obtain virus protection from the Micro Lab and put it on his
Macintosh. With a good bit of publicity, this might be successful.
        Another problem which we have had to deal with is recurring
system crashes on our AppleShare servers even after the eradication of
WDef. Although WDef if "officially" gone thanks to Disinfectant v1.6,
the servers still seem to crash regularly. It appears that WDef, like
polio can be cured, but it leaves lasting damage. The only solution I
have found is to delete the unused DESKTOP file on all server volumes.
This brought the number of crashes down from four a day to zero for a
week.

                Paul Duckenfield
                Carleton College
                CC User Services
                Micro Consultant
              [e-mail]

------------------------------

Date:    Mon, 19 Feb 90 10:13:57 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Effects on checksum programs (PC)

I wonder if the readers of this group have considered the effects of
viruses like "The Number of the Beast" (alias "512" or "666") on
checksum programs.

As Vesselin Bontchev has pointed out, if the virus is active in
memory, no changes to the infected program will be seen, since the
virus will redirect any attempts to read the file so the original,
non-infected file will be read instead.

This means that with the virus active in memory no checksum program
will be able to detect infection of files, NO MATTER HOW STRONG THE
ALGORITHM used.  All the discussion on which algorithm to use is
therefore rather pointless...

This is not a problem if the computer is first booted from a
non-infected diskette, but how can one be sure that COMMAND.COM on the
diskette was not infected ?

- --
Fridrik Skulason,  University of Iceland
E-Mail: [e-mail]                  Technical Editor, Virus Bulletin (UK).
Fax: [phone]

------------------------------

Date:    Mon, 19 Feb 90 10:10:20 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: New variant of Cascade/1704 (PC)

Some time ago I reported that 1704 seemed able to infect the same file
over and over on a Novell network.

I now have a copy of the virus in question, and it appears that this
has nothing to do with Novell networks - it is just a new variant of
the virus.

It is possible that this virus was created by a random mutation, which
seems to have changed one JA instruction into JNE, but it is not
certain.

Because the author of 1704 did not include self-correcting Hamming
code in the virus :-), the mutation spread - and spread faster than
the original, "healthy" variant.

All programs which are able to detect and remove the "standard" 1704
virus should also be able to handle this variant.

- --
Fridrik Skulason,  University of Iceland
E-Mail: [e-mail]             Technical Editor, Virus Bulletin (UK).
Fax: [phone]

------------------------------

Date:    Mon, 19 Feb 90 10:12:12 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: F-PROT news (PC)

A week ago I reported that version 1.08 of F-PROT would become
available in a day or two - but unfortunately I have not been able to
get it out the door until now.

I apologize to everybody who has been waiting (in particular the 50
persons or so that I have promised a copy by E-mail), but I believe it
was worth the wait.

The reason for the delay was the arrival of 30 different virus
variants from Bulgaria. As 26 of them were previously unknown, I had
to write a number of new disinfectors - which has taken up most of my
spare time the past week.  I have also added code to detect and remove
some other new viruses, like Devil's Dance, "1260", "E.D.V." and
"Hallochen".

Those of you having a copy of 1.07 can update it by adding the
following new entries to the SIGN.TXT file:

Dance       BERj85djAtm5nmjXFAufHKK9H85FJcdKH9hO0Mn5adeD0535Ip
New Vienna  CVRmsm3je7W2jWGfkBBzbMdVnf7r9Ai3sYcyCyduVhSKEO
New Vienna  pVBmtjP5WtsnGfkb1Xwu1mfb5j7EqqOAAIvdFBIrkRjuxUZmcZZvR2
Pixel       fBTMD5a5KdRMGEI4nROAAeJMhnDtHqQMpmNMU25MnME7Yq+Zfr
Eddie-2     X7Jjsmsm7euUMCFun90jkFfuSISWK6icEfuo4KP97ul4MNwlObmt
512         JENmS5rMi5PFbjjjCdYV4-UjAUguForRGswWc8jf6ZyhE81rEMPo3V
Old Yankee  iEpMSjsmEmEY4Am4-upjU5357XVcxXA2mMDTG4TRUctKfNq-Wh
E.D.V.      87u5djDjddmmFZ-d8MiRxONMAdTMBM7V5fgAAeJwNbZ4QMK6jmwLit
Hallochen   S7UjF5PMiiTm74Mo6RMqYY65jnm57KlIt8lqPKWm4ETQi3R5pMmBMf3u

Version 1.07 is not able to handle the 1260 virus, since no ordinary
identification string can be provided for it.  I had to make some
changes to the program itself.

Other changes from 1.07 to 1.08:

The F-DRIVER.SYS program did not display a message saying it had been
installed, as stated in the documentation.  This has been corrected.
This answers the question from Scott D. Gregory - yes, it is working,
even though it is only 1.5K in size.  Well, actually version 1.08 is a
bit longer, it is closer to 2K, but I just finished testing it and it
stops every single virus in my collection, (which is one of the
largest around).

F-DLOCK.EXE contained a bug that prevented it from working with the
CHKDSK program.  This program could also cause some problems in other
cases. This has now been corrected.

F-OSCHK would display a warning message in Icelandic, if it found that
a change had been made to the operating system - I has forgotten a
"#ifdef ENGLISH" somewhere. This has been corrected.

SIGN.TXT does no longer have to be in the current directory - it may also
be located in the same directory as the F-FCHK program.

Finally - a reply to Ron Warren Evans.

> He points out that F-PROT is virtually unknown in the U.S.,

That's true - I only finished the English version a short time ago,
but the Icelandic version has been on sale for several months now and
has been very successful here in Iceland.  The market here is however
very small, only 0.1 % of the U.S. market.

> is produced by a lone Icelandic programmer,

How true - sometimes I wish I was a huge multinational corporation :-)

> is untested here

Well, not quite - several people have been playing with it for a few
months. Anyhow - most of the bugs should be gone by now - the people
here in Iceland who bought versions 1.00 to 1.06 probably managed to
find most of them. :-)

> and may not be well-supported.

Well, that depends on what kind of support you want - If you are
looking for a product that comes with a 24-hour hotline support and
on-site servicing you should look elsewhere. However - you would have
to pay more than what I am asking for.

I am just trying to provide powerful programs, able to catch all known
viruses and remove them.  I believe my programs contain some useful
features, not found elsewhere, although they are not perfect.  They
could be made easier to install, perhaps intergrated in one package,
but I will not make changes like that until I write version 2.0.

Support - well, for now, E-mail will just have to do.... :-)

- --
Fridrik Skulason,  University of Iceland
E-Mail: [e-mail]                  Technical Editor, Virus Bulletin (UK).
Fax: [phone]

------------------------------

Date:    19 Feb 90 22:07:40 +0000
From:    [e-mail] (Ron Rymon)
Subject: Certus (FoundationWare)


 I need information about a product named Certus (man. and dist. by
FoundationWare). Have anybody heard/used it?

 I would appreciate sharing your experience. Particularly I am interested
in the type of instalation (single PC? LAN?), how many used in the site?
For how long? and how friendly it is? How effective?

 Thanks a lot,

Ron

Ron Rymon

------------------------------

Date:    20 Feb 90 18:55:25 +0000
From:    Paul Andrews <tenset![e-mail]>
Subject: Gatekeeper 1.1.1?


I have a couple of questions:

1) What is different about gatekeeper 1.1.1 and the previous version (1.0?)?

2) Where can I get it? The problem here is that UUNET (or EUNET or whatever)
   has a message size limit of 100k. The INFO-MAC archive file for gatekeeper
   1.1.1 is >100k and we can't use ftp from this side of the pond. (In case
   your wondering, I would normally use a listserv which fetches files from
   INFO-MAC for me).

3) Does gatekeeper aid 1.0.1 NEED gatekeeper 1.1.1 or will it work with 1.0.?

- - Paul.
- --
- ------------------------------------------------------------------
| Paul Andrews             | Post: Tenset Technologies Limited,  |
| [e-mail]         |       Norfolk House,                |
| Phone: [phone]    |       301 Histon Road,              |
| Fax:   [phone]    |       Cambridge CB4 3NF, UK.        |
- ------------------------------------------------------------------

------------------------------

Date:    Tue, 20 Feb 90 14:19:00 -0600
From:    "Paul Duckenfield (Consultant, User Services)" <[e-mail]>
Subject: WDEF details (Mac)

>From:    [e-mail] (Wing Leung)
>Subject: More about WDEF

>        Can someone tell me is WDEF an illegal string in the resource code?
>        How about the program called WDEF uploaded in comp.binaries.mac?
>        In fact, I've found some WDEF code in system version 6.0.3
>        Please tell me more about this resource code.

        WDef is a system resource which (basically) tells the Mac how
to draw its windows. There are several programs in the FREE/SHAREware
market which change how the window appear on your Macs screen. They
make it look like a NeXT or MS Windows or some other form other than
the "standard Apple"-look. They take advantage of the WDef resource in
the SYSTEM file.

        The virus WDef is a little trickier. It infects the invisible
DESKTOP file in the root directory of any disk. You can't seem this
file, but it is there, keeping track of all your files.

        That is the difference between WDef SYSTEM resource and WDef
DESKTOP resource (for the layman).

        Incidentily, I have heard reports that it is possible
(although not easy) for someone to rename the WDef virus's resource to
CDef. Potentially this will create another virus, exactly the same as
the first except for the name, which can propogate quickly as well.
Anyone know anything about this?

                Paul Duckenfield
                CC User Services
                Micro Consultant
                [e-mail]

------------------------------

Date:    Tue, 20 Feb 90 16:49:32 -0800
From:    [e-mail]
Subject: SCAN and the Brain (PC)

The following is forwarded from John McAfee:
============================================================================

        Michael Kapfer stated in yesterday's posting that SCAN will
not identify the Brain virus in memory.  This is not entirely correct.
If you specifically ask for a memory scan (/M) then SCAN will identify
the virus if it is active.  If you do not ask for a memory scan, then
SCAN will in any case scan memory for the "critical" viruses like
4096, Dark Avenger, 512 etc.  It is this default memory scan that
Michael is talking about, and it indeed will not look for the Brain.

John McAfee

------------------------------

Date:    Tue, 20 Feb 90 15:31:00 -0400
From:    Ivy Anderson <[e-mail]>
Subject: RE: Disinfectant 1.6 (Mac)

I am brand new to VIRUS-L and to virus protection in general.  I have
just read the posting which mentioned Disinfectant 1.6, a free
ant-virus program.  Can someone advise me where we can obtain more
information about this program?  Is there a PC version as well?

Thanks very much,

Ivy Anderson
Brandeis University Libraries

Bitnet:  anderson@brandeis
Internet:  [e-mail]

------------------------------

Date:    21 Feb 90 15:28:30 +0000
From:    rigel![e-mail] (23384-mitchell)
Subject: RE: Trojan Horses != Copy Protection

In an earlier posting, someone attempted to justify the reprehensible
behavior of the author(s) of the AIDS Trojan Horse as a copy protection
system.
IMHO, I beg to differ - there is a key differences between the behavior
of legitimate copy protection systems and the AIDS Trojan.
It would be legitimate for a copy protection system to remove the protected
program from the disk or otherwise render it unusable to unauthorized users,
but it is NOT legitimate (at least in the USA) for the copy protection system
to destroy, encrypt, or otherwise render unuseable programs or files that
are totally unrelated to the protected program.
An analogy:  Under the laws of the USA, if I loan you the money to pay for
an automobile, the standard loan contract that I will have you sign gives
me the legal right to recover "repossess" the automobile if you fail to make
the loan payments on time.  However, it does NOT give me the right to
confiscate your lawn mower, snow blower, wheelbarrow, and whatever else you
happen to be keeping in your garage along with the said automobile.
Removing any other personal property is considered to be THEFT and is
strongly discouraged, to say the least, by the authorities.
IMHO (this is only my opinion, however I am not an attorney, you
should consult with legal counsel for legal advice) the poster who said that
the magazines that published information about how to work around the problems
caused by the Trojan Horse were liable for damages to the work of the
Trojan Horse author(s) and his/their alleged company's reputation
was totally off base.  IMHO, these magazines performed a valuable
service to the computing community and their behavior was totally consistent
with recogized computing community codes of ethics (e.g. ACM, IEEE).
We are not talking about legitimate
copy protection here, rather I think the appropriate term is "Extortion,"
which seems to be the term used by the legal authorities in the UK who are
bringing criminal charges in this matter.
IMHO, swift prosecution followed by a stiff penalty, if convicted, is the
best way to put an end to such incidents.
While I certainly favor using the USENET as a forum for the free expression
of ideas, IMHO postings calling outright extortion a valid form of copy
protection do no one any good and give the net a bad name.

Regards,
Bill Mitchell

Disclaimer: These are strictly my personal opinions and not
necessarily those of my employer or any other person.  I am not an
attorney and am not providing any legal opinions or advice here.
Consult with your attorney for legal advice.


------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest   Thursday, 22 Feb 1990    Volume 3 : Issue 47

Today's Topics:

Re: WDEF details (Mac)
Re: AIDS Copy Prtection System
New Virus turns up at U. of Pa! (Mac)
1813 Virus sighting (PC)
Bogus Version of SCANV58 (PC)
UVD
PC Cybrog
Re: Disinfectant 1.6 (Mac)
Re: Idea for WDEF Innoculation (Mac)
AIDS Trojan (PC)
Safety of Boot Disk (PC)
Israeli virus strains vs. Novell? (PC)
US H.R. 55
VALIDATE.EXE (PC)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

---------------------------------------------------------------------------

Date:    Wed, 21 Feb 90 12:35:38 -0500
From:    Joe McMahon <[e-mail]>
Subject: Re: WDEF details (Mac)

Paul Duckenfield <[e-mail]> writes:
>    ... Another problem which we have had to deal with is recurring
>system crashes on our AppleShare servers even after the eradication of
>WDef. Although WDef if "officially" gone thanks to Disinfectant v1.6,
>the servers still seem to crash regularly. It appears that WDef, like
>polio can be cured, but it leaves lasting damage. The only solution I
>have found is to delete the unused DESKTOP file on all server volumes...
                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
By all means do that.  The virus will still write to this file (if
you've allowed your client machines access to it) and will be lurking
there, waiting for you to boot the server from a floppy. When you do
that, the AppleShare Desktop Manager INIT is bypassed and you have a
new source of infection. Also, be warned that rebooting from a floppy
will cause the Desktop file to be *rebuilt* on the server! You will
have to remove it again.

Paul also notes/asks:
>        Incidentily, I have heard reports that it is possible
>(although not easy) for someone to rename the WDef virus's resource to
>CDef. Potentially this will create another virus, exactly the same as
>the first except for the name, which can propogate quickly as well.
>Anyone know anything about this?

Doubtful. I don't have my handy copy of Inside Mac right here at the
moment, but as I recall, the calling sequences are quite different.  I
believe that there would be trouble (i.e., crash/hang) if you tried
it. However, if the viral WDEF does its infections directly, it might
be able to spread itself before the crash occurs. I don't think that
it would spread as fast as WDEF, because the behavior of the Mac would
take such a sudden turn for the worse that almost anyone would become
suspicious. Also, if you're running GK Aid or Eradicate'em, you're
already protected against anything which looks even remotely
executable in the Desktop file.

 --- Joe M.

------------------------------

Date:    Wed, 21 Feb 90 19:27:03 +0000
From:    [e-mail] (James R. B. Davies)
Subject: Re: AIDS Copy Prtection System

Ian Farquhar (munnari!mqccsunc.mqcc.mq.oz.au![e-mail])
has posted two notes here recently claiming that the AIDS trojan was a
copy protection scheme.  This has not been a popular idea among
respondents, but they have mostly been addressing themselves to the
immorality of trashing someone's hard disk and the lack of the
promised remedy after "registration".

I think that a more damning feature of the AIDS program is that it
would give the victim some "free" reboots if he would carry it to
another computer and infect it.  While this could be construed by some
(like Mr. Farquhar, no doubt) as being analogous to the incentives
offered by book clubs for enrolling new members (sign up a friend, get
a free book), this to me seems clear evidence that the intent was
malign (as if more evidence is really necessary).  In particular, the
new victims were not necessarily given the benefit of reading the
"license agreement" as the original recipient was.

In any case, Mr. Farquhar is either being intentionally dense to
provoke arguments, or he has some bone to pick with commercial
software vendors that use copy protection and hopes to cast them in a
negative light by associating them with this scam.  I personally don't
see any reason why someone who is clearly responsible for this trojan
wouldn't get convicted, as the overwhelming evidence is that this was
extortion.

                                                  jrbd

------------------------------

Date:    Wed, 21 Feb 90 14:00:00 -0400
From:    Michael Greve <[e-mail]>
Subject: New Virus turns up at U. of Pa! (Mac)

      I think a new MAC virus has turned up here at Penn.  A
co-worker/student gave me a disk with some papers he wanted laser
printed.  When I put the disk into my machine Gatekeeper Aid remove a
WDEF A virus then I got a message saying "GateKeeper found an "Implied
Loader 'INIT'" virus, it has been removed".  I'm glad Gatekeeper Aid
caught it!  I think mention was made of this virus a week ago.  Is
this a new virus??  What does it do??  Is it spread like WDEF A??  I'm
using Gatekeeper Aid 1.0.1.  Will/Can Disinfectant 1.6 catch this
virus.  All these questions....

                                                  Michael Greve
                                                  Univ. of Pa.
                                                  Wharton Computing
                                                  [e-mail]

------------------------------

Date:    21 Feb 90 13:26:56 -0600
From:    "Tom Kirke [phone]" <[e-mail]>
Subject: 1813 Virus sighting (PC)

This little fellow has shown up at the University of Illinois at
Chicago.  Scanres found it on a machine in the public labs in the
computer center.

Tom Kirke                   |      All standard and non-standard
[e-mail]         |  disclaimers, declaimers, and claimers
[e-mail]     |                 apply.
[e-mail]@DASNET#

We have discovered a *therapy* (NOT a cure) for the common cold,
                  play tuba for an hour.

------------------------------

Date:    Wed, 21 Feb 90 13:12:36 -0800
From:    [e-mail]
Subject: Bogus Version of SCANV58 (PC)

This is a forward from John McAfee:
============================================================================

          We have received reports of a SCANV58.ZIP file that contains a bogus
VALIDATE program.  The program is an EXE file (the real validate is a COM
file) and is 46,167 bytes long versus 6,485 for the original VALIDATE.  There
have been reports of system damage from the use of this program and under no
circumstances should it be used.
          The authorized version 58 of scan is 42,977 bytes long, has a
creation date of 2-15-90 and the validation checks should be: Method 1: 2F16
and Method 2: 1C57.
          If you come accross the bogus version and have information about
where it came from, then please contact me at 408 988 3832.  The bogus
validate program appears to be identical to a program uploaded to HomeBase
on 2-19-90 by a person usinmg the name Richard Levey.  The documentation
for the program contained a copyright by Richard Levy, but there was no
phone number or any other contact information provided.
          As you can imagine, we are very anxious to find this person and if
anyone has any information then please call.

John McAfee
408 988 3832 (voice)
408 970 9727 (FAX)
408 988 4004 (BBS)

------------------------------

Date:    Tue, 20 Feb 90 21:17:38 -0500
From:    [e-mail]
Subject: UVD

   "David.M..Chess" <[e-mail]> writes:

>> VDOS pseudo-executes the program, checking for
>> every possible outcome and attempts to write to disk.
>
>Unlikely to be practical, I'm afraid?  For instance, if the program
>waits for user input, or looks at the time or date, or reads from a
>file (I can't think of -any- program offhand that doesn't sometimes do
>at least one of these), the pseudo-executor would have to
>pseudo-execute a separate instance of the program for every possible
>input/time/data-item.  Not likely to finish within the life-expectancy
>of the user!

   A seperate instance for every possible input?  Nonsense.
All that is required is a seperate instance for every alternative
in a conditional structure.  Of course, that can still require a
large number of instances, and some data will be undefined, so it
would be necessary to rule out entire classes of operations where
it is unacceptable for some parameters to be unknown (such as
direct writes to the disk where the location to be written to is
unknown).  But many such activities would be 'suspicious' anyway.
Another method of verification in which the values of data are
unknown and which requires no seperate instances of a program is
to examine the code as if all alternatives of a conditional structure
are taken.  Once again, it is necessary to rule out certain actions
when data values are unknown.  Remember, however, most instructions
are not suspicious even when all parameters are unknown.  Also, in
conditionals in machine languages there are only two alternatives in
a conditional branch (branch or don't!).  Still, if one tried to simulate
every possible path through any decently large program the number of
instance doublings (every time there is a conditional jump you get two
possible paths) would quickly eat up memory and it would take a *long*
time.  But since it isn't necessary to simulate every possible input,
I think the simulation would terminate within the average user's lifetime.
_________________________________________________________________
David Conrad       BITNET: [e-mail]
"He hates the sight of liquor.  That's why he drinks so much.
   To get it out of sight quickly."

------------------------------

Date:    Wed, 21 Feb 90 20:25:09 -0500
From:    Kim Dyer <[e-mail]>
Subject: PC Cybrog

I sincerely hope that Ian Farguhar is playing devils advocate.  It's
scary to think someone is actually DEFENDING acts of electronic
terrorism.  (Extortion sort of implies you CAN deliver ... you pays
your fee and your club doesn't burn down.  I've seen no evidence that
PC Cyborg could cure/prevent the damage caused by the AIDS disk.)

I haven't seen any information yet on whether or not Australia and
the European countries the AIDS disk showed up in have laws that
protect consumers from unordered merchandise.  I know that US laws
do not apply ... and I know that no one has said they do.  If, however,
similar laws do NOT exist elsewhere, I'd sure be getting on my
legislators case to enact them quickly.  SOMEONE please enlighten us.

Perhaps my economic woes are over.  If there are no laws protecting
Australian citizens from this sort of scam, maybe I can pack up tons
of dog hair and mail it to random addresses in Sydney for use as packing
materials.  Bill at rate of $100 an ounce included ;-).

------------------------------

Date:    Wed, 21 Feb 90 16:51:39 -0600
From:    John Norstad <[e-mail]>
Subject: Re: Disinfectant 1.6 (Mac)

[e-mail] writes:
>       I realize that Mr. John Norstad just released Disinfectant 1.6
> and has again announced that Disinfectant 2.0 is forthcoming, but has
> he or his colleagues announced WHEN we can anticipate its release?

I wish I knew.  It will be at least a few months, probably longer.
The big problem is that I keep getting ideas for new features faster
than I can implement them.

John Norstad
Northwestern University
[e-mail]

------------------------------

Date:    21 Feb 90 17:51:43 +0000
From:    [e-mail] (Steve Lasich)
Subject: Re: Idea for WDEF Innoculation (Mac)

[e-mail] (Christopher Tate) writes:
>The big problem with this is that since the WDEF-removal code is itself
>a virus, it stands a big chance of causing the same problems as any other
>virus -- crashes due to poorly written code.

>There have been no viruses written to date for the Macintosh which
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^
>deliberately cause damage to the system (*).  All of the problems caused
                                               ^^^^^^^^^^^^^^^^^^^
>by existing viruses are in fact the result of bugs in the viruses, which
>causes interference with other programs under certain circumstances.
>Since the above-mentioned inoculation program would be a virus itself,
>it might well cause problems itself.

I have seen this assertion made a half dozen times.  Can somebody
either confirm or deny the report I read in either MacUser or MacWorld
(circa October 1988) that there is malicious code in the SCORES virus
which is only activated by the presence on a disk volume of files
containing certain creator IDs belonging to Electronic Data Systems
(EDS), the company which Ross Perot sold to GM?  I apologize if this
is an old question that has been answered a hundred times already.

>(*)  Mosaic and Font Finder are not viruses (they do not replicate), but
>     are instead "trojan horses" -- destructive code hidden within an
>     innocuous-seeming program.

>Christopher Tate                       |

- ----------
Steve Lasich   Micro Lab Coordinator
[e-mail]
..rutgers!mailrus!sharkey!clmqt!steve

------------------------------

Date:    Wed, 21 Feb 90 16:56:14 -0500
From:    [e-mail]
Subject: AIDS Trojan (PC)

munnari!mqccsunc.mqcc.mq.oz.au![e-mail] (Ian Farquhar) writes:
>...As for the concept of the user having legal control over what was
>deleted from his/her hard disk, I cannot see this as a problem.
>Multi-user systems have traditionally provided mechanisms for the
>superuser to control the user's files with far more privileges
>than the users themselves....

So intellectual property may be destroyed by anyone at any time and
the owner has no recourse whatsoever?  If current laws say this, then
it is another failure by those who created our laws to provide adequate
protection of intellectual property.  The parallel with multi-user
systems is flawed, in that in a multi-user system a user *knowingly*
grants the superuser certain privileges in exchange for the system
being efficiently organized, and *with the understanding that the
superuser will *not* abuse those privileges*!

   What the AIDS program did was most likely illegal, but what's even
more important, it was entirely unethical.  As to the response here,
all I've seen are warnings not to run the program (in light of what it
does), and perhaps there was some advice on how to recover files that
the program took hostage.  Telling people how to recover their legal
property is hardly wrong.  What I haven't seen are instructions on how
to run the AIDS program despite its "copy protection", which would
violate the rights of the author.

   Creating disassembled listings of the program would, unfortunately,
violate the author's right to create derivative works, but I see this
as a necessary evil in the highly ethical process of attempting to
restore the legal property of victims of this program.

Ian also writes:
>...If I were the defense lawyer with access to this newsgroup, the
>first thing that I would have done is to take all of the relevant
>articles that have appeared, and present them as evidence
>prejudicial to the fair conduct of the trial....

Fine, but you'd have to show that the jury members had read the articles.

Ian also writes:
>...There also is a strong reluctance to change an opinion in the light
>of new evidence, which is very worrying indeed....

Just remember, Ian, you said it!
___________________________________________________________________________
David R. Conrad              BITNET: [e-mail]
"Monday is an awful way to spend one seventh of your life."

------------------------------

Date:    Wed, 21 Feb 90 17:09:10 -0500
From:    [e-mail]
Subject: Safety of Boot Disk (PC)

[e-mail] (Fridrik Skulason) writes:
>...the computer is first booted from a non-infected diskette, but
>how can one be sure that...the diskette was not infected?

At present, of course, the only way is to keep a backup of the operating
system release diskettes, and to pray that the makers of the OS are not
infected.  I hope the major (and minor, for that matter) OS publishers
use the very newest and best virus protection softward available.
If they don't, then God help us!  Perhaps the virus protection people
will eventually come out with a bootable (no DOS required) virus checker!
_________________________________________________________________________
David R. Conrad              BITNET: [e-mail]
Disclaimer: Hey, wait a minute!  These aren't my opinions!
"If anything can go wrong, then it probably already has."

------------------------------

Date:    Thu, 22 Feb 90 10:15:43 -0500
From:    [e-mail]
Subject: Israeli virus strains vs. Novell? (PC)

Good evening,

recently, a user of a Novell Network consulted me about my (ancient,
even obnsolete, yet popular) VIRCHECK program, which had rendered his
network hanging.  He declared, that Novell uses Int 21, Function E0,
for its internal gearings -- the very same function the "Friday 13th"
virus uses for its signalling.  My VIRCHECK will check for the
presence of TSR "Friday 13th" by invoking this function and looking at
the answer.

Now I conjecture, that
** the "Friday 13th" will cause Novell Networks to hang every time an
   infected program is invoked;
** so will probably other Israeli strains do (Y.R. forgive me: I don't
   know any other, widely recognized, term for them :-) ;
** IMMUNE and similar virus-watchers will probably suspect Novell
   of being a virus, and alert the user about it;
** VIRCHECK and similar virus-checkers will cause Novell to hang,
   as well.

Has anybody any experiences to share with us, in this respect?
(I, for my part, have no Novell running to test my conjectures.)

Best wishes
            Otto Stolz

------------------------------

Date:    21 Feb 90 21:09:37 +0000
From:    pyrdc!inco![e-mail] (Bo Newman)
Subject: US H.R. 55


This may be a rehash of an old topic and if it is, I apologize at
the start.  The FOLLOWING VIEWS ARE IN NO WAY ATTRIBUTABLE TO
ANYONE OTHER THAN ME.

- ----------

Does anyone know what the status of US H.R. 55 is?  H.R. 55
introduced in July of 89, is a follow-up to the 1986 Computer Fraud
and Abuse Act.  It addresses, in part,  computer virus designed
with "authorized " assess to computers, or viruses that are not
designed to delete files.  According to Rep Wally Herger (R-Calif)
this bill was supported by a number of computer lobbying groups.


What concerns me most was that it was reported that H.R. 55
establishes tough penalties(up to 20 years in prison) for;

     "knowingly" planing a virus that causes "loss, expense,
     or risk to the health or welfare" of an individual or a
     company.

This would seem to open the provider/installer of any software at
risk of libel.  Software has bugs, like it or not.  (Also remember
that in layman's vernacular the common cold is caused by a
bug/virus without much distinction) If the presence of a "bug"
results in a "potential" risk to the health or welfare(?) of an
(individual or) company you as the provider/installer could find
yourself facing 20 years in jail.  If this is the case, the
liability insurance problem faced by the medical profession will
be nothing compared to what the software industry will face.

With the way the federal Racketeer Influenced and Corrupt
Organizations Act (RICO) has been used in civil court, it is very
hard to bank on "intention of congress" when it comes to the way
a law will be applied.

RICO was designed as a weapon to protect legitimate business from
organized crime.  But civil claims have been filed under it in
cases of bank fore-closures on real estate, between doctors and
hospitals over staff privileges, to cases between warring spouses
in divorce cases and child custody battles.

The parallels for misuse of the provisions of H.R. 55 seem too
obvious.

     You have just converted your companies market information
     system to a new Relational Database product that contains
     a bug. Because of that bug you are unable to retrieve key
     marketing information and as a result the "well being"
     (market position) of your company is now "at risk."

Will this be grounds for prosecution or a civil suit?  Before you
answer, consider the RICO situation.

When RICO was enacted it was mostly ignored, as was the 1986
Computer Fraud and Abuse Act until the Morris case). But around
1980, plaintiffs' lawyer started seeing the potential for applying
RICO to individuals other than typical racketeers.  The number of
civil RICO cases increased eightfold for the early 1970s to the mid
sixties.

The increased cost for defending against litigation brought under
RICO and the costs of higher insurance premiums end up coming out
of the consumers pocket.  If the same situation develops as a
result of law based on H.R. 55 the impacts could be felt in almost
every sector of the economy.

But then for those brave soles who are still willing to face the
risks of the lawyers, writing software may become a vveerryy well
paying profession.

===================================================================
:Bo Newman           [e-mail]       uunet!inco!newman         :
- -------------------------------------------------------------------
:  ALL STANDARD DISCLAIMERS APPLY AND THEN SOME                         :
===================================================================

------------------------------

Date:    Wed, 21 Feb 90 19:29:00 -0500
From:    IA88000 <[e-mail]>
Subject: VALIDATE.EXE (PC)

Last night someone upload scanv58.zip to my bbs which contained a
different version of validate by another author.

The program clearly states the author's name and the documentation
clearly indicates it was not written by McAfee and Associates.

I carefully unzipped the files and checked them all for virus and/or
trojan infections. THERE WERE NO VIRUS REPORTED!

Just to be safe, I used SOURCER to check VALIDATE and there were
NO suspicious or dangerous routines in the program. It does exactly
what it claims to do, that is it opens a file, reads the file a
block at a time, and generates four CRC's for the file.

I ran it and it runs fine. Absolutely no problem whatsoever!In fact
it seems to be slightly faster than McAfee's validate.com and it
generates four CRC's instead of two.In the documentation the author
claims to use proprietary forumlas for generating the CRC's.

Today, I get a message in VALERT about this program. According to
Mr. McAfee, it is bogus and supposedly damaging systems. Nothing could
be further from the truth! The VALIDATE.EXE does one thing which it
is obvious Mr. McAfee does not like. That is (in my opinion) that
it leaves his version of validate in the dust.

Mr. McAfee negelected to mention that in the documentation it appears
there is a question as to who owns the rights to the name VALIDATE.
I called HOMEBASE and downloaded the real scanv58 and with the
exception of the different validate.doc and validate.com found
the other files to be exactly IDENTICAL. This being the case it seems
to me that Mr. McAfee is complaining over nothing. The version of
SCAN is correct and is not damaged or changed in any way.

It seems to me that the author just deleted Mr. McAfee's version of
validate and included his own in the archive file. It appears no changes
were made to SCAN and as such I don't see what McAfee is complaining
about, unless he is attempting to claim a copyright on the contents
and/or makeup of the scanv58 archive file?

The only thing bogus about this whole matter is the fact that McAfee
sent out a VALERT notice about it. Especially since he claims that
validate was uploaded to HOMEBASE several days ago and he had plenty
of time (so it appears) to make comments before this.

In my opinion the author of validate has done the community a favor
by replacing the program in the archive file with one that appears
to do a better job.

As far as the program names are concerned, so what? I checked over
five different copies of McAfees validate and none of them mention
that he has a trademark on the name validate. The validate.exe does
have a trademark notice,      and as such that should be the one
and only program to use the name validate.

If mcafee can provide absolute proof that validate.exe damages
systems as he claimed in valert, let him do so by producing the
source code to prove his claim. As I mentioned earlier SOURCER
was used to disassemble the validate.exe and there is no evidence
of any code which could damage a system. In fact the only code
which accesses the disk opens the file for READ and then closes
it at the end of the program. The only memory accesses appear to
be a large numeric array set up to read the file into and the code
which reads the array and generates the CRC's. There is nothing
dangerous in this program whatsoever (in my opinion).

I also read the documentation and the alleged author's name is
clearly there, as well as complete information on the validate.exe
program. It appears to be a shareware pro